Command Palette

Search for a command to run...

UnylyUnyly
Весь каталог

Wikidesk Server

БесплатноНе проверен

MCP server that wraps LLM-wiki into a shared research service for AI coding agents.

GitHubEmbed

Описание

MCP server that wraps LLM-wiki into a shared research service for AI coding agents.

README

A companion server for LLM-wiki that turns named wiki repos into shared knowledge services for multiple AI coding agents. wikidesk doesn't care how your wiki is organized, what agent runs the research (Claude Code, Pi, OpenCode, Codex, etc.), or what prompts you use -- each configured wiki name just needs a derived repo directory holding the actual wiki content (wiki-{name}/wiki/, except default uses wiki/wiki/).

The primary workflow is simple: agents read local wiki mirrors directly as knowledge bases. Mirrors default to wiki-{name}/, except default uses wiki/, and clients can override them. On top of that, wikidesk optionally provides a research tool that lets agents request new research -- dispatching a dedicated research agent to investigate the question, update the server wiki repo, and return an answer. Whether your agents can trigger research or only read is up to you, controlled by your agent rules.

How it works

wikidesk overview architecture

  1. Agents read configured local mirror directories for existing knowledge
  2. When an agent needs new research, it submits a question to /wiki/{name}/mcp or /wiki/{name}/api/research
  3. The server queues the question for that wiki and spawns its configured research agent
  4. The research agent investigates the question, potentially creating or updating pages under the server wiki repo
  5. The answer is returned with [[wikilinks]] resolved to the client's local mirror path
  6. Agents sync their local wiki copies automatically

Agent rules

Configure your agents to use the wiki by adding rules to your CLAUDE.md, AGENTS.md, or equivalent:

Read-only (agents consult the wiki but never trigger research)
## Wiki

* The configured wiki mirror directory contains a knowledge base on <your topics>.
  Consult it before making decisions in these areas.
* Do not modify wiki files directly.
Read + research (agents can request new research via MCP)

N.B.: tool names use Claude Code conventions in the snippet below.

## Wiki

* The configured wiki mirror directory contains a knowledge base on <your topics>.
  Consult it before making decisions in these areas.
* Do not modify wiki files directly.
* When the wiki doesn't cover a topic you need, use that wiki server's `research` MCP
  tool to request investigation. Poll `get_result` until the task completes,
  then sync your local wiki copy.

Automatic wiki sync (client-server mode)

In client-server mode, local mirror directories need to stay in sync with the server. You can automate this using your agent harness's lifecycle hooks to run wikidesk sync at the start and end of each session.

Claude Code -- hooks in settings.json

Add to your project's .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "*",
        "hooks": [
          {
            "type": "command",
            "command": "wikidesk sync"
          }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "wikidesk sync"
          }
        ]
      }
    ]
  }
}

Or ask Claude Code to set it up for you:

Set up hooks in .claude/settings.json so that wikidesk sync runs on PreToolUse (all tools) and Stop. The environment variables WIKIDESK_SERVER_URL and WIKIDESK_WIKIS are already set in the shell.

Cline / Roo Code -- custom instructions with task hooks

Cline and Roo Code support custom_modes with tool-use hooks. Add a sync step to your custom mode's whenToUse or use the built-in command execution to run wikidesk sync at task boundaries. Refer to your extension's documentation for the exact hook configuration.

Other harnesses -- general approach

Most agent harnesses support some form of lifecycle hooks or pre/post commands. The pattern is:

  1. Before the agent starts working: run wikidesk sync to pull the latest wiki state
  2. After the agent finishes: run wikidesk sync to pick up any changes from concurrent research

Check your harness documentation for:

  • aider: --run flag or .aider.conf.yml commands
  • OpenCode: lifecycle hooks in configuration
  • Cursor: task/command configuration in settings

Security

The research agent runs with full permissions. The agent_command typically includes flags like --dangerously-skip-permissions (Claude Code) or equivalent settings that grant the child agent unrestricted system access. This is intentional — the research agent needs to read and write wiki files AND query random websites — but it means the research agent or the server spawning it must run inside a sandbox. Of course you can allow-list specific tools, websites etc. but in general case you want the LLM-wiki agent to freely browse the internet.

Recommended approaches:

  • Docker/Podman: Mount only the wiki repo and config into the container.
  • bubblewrap (bwrap): Minimal Linux sandboxing with filesystem and network restrictions.

I'm using a custom Nix+bubblewrap-based sandboxing tool (not yet released) for development.

Server setup

1. Install wikidesk-server

macOS / Linux (pre-built binary)
curl --proto '=https' --tlsv1.2 -LsSf https://github.com/ilya-epifanov/wikidesk/releases/latest/download/wikidesk-server-installer.sh | sh
Windows (pre-built binary)
powershell -ExecutionPolicy ByPass -c "irm https://github.com/ilya-epifanov/wikidesk/releases/latest/download/wikidesk-server-installer.ps1 | iex"
From source (any platform with Rust 1.88+)
cargo install wikidesk-server

2. Set up your LLM-wiki

Follow the LLM-wiki setup instructions to create and configure each wiki repo. Name each repo wiki-{name} next to config.toml; the special wiki name default uses repo directory wiki. wikidesk requires each repo to contain a wiki/ content root. Keep wikidesk prompt templates outside that content root so the research agent cannot edit its own prompt.

3. Create a configuration file

See config.example.toml for all options.

# config.toml
bind_address = "127.0.0.1:1238"

[[wikis]]
name = "rlhf" # derives ./wiki-rlhf and /wiki/rlhf
description = "RLHF, preference optimization, DPO/PPO/GRPO/RLOO, reward modeling, and alignment training methods."
prompt_template = "prompts/rlhf.md"

# SECURITY: This command runs UNSANDBOXED by default.
# See the Security section -- always run the server in a container.
agent_command = ["claude", "-p", "$PROMPT", "--dangerously-skip-permissions"]

4. Start the server

wikidesk-server --config config.toml

5. Run as a daemon (optional)

To keep the server running across reboots:

Linux -- systemd (user service)
mkdir -p ~/.config/systemd/user

cat > ~/.config/systemd/user/wikidesk.service << 'EOF'
[Unit]
Description=wikidesk research server
After=network.target

[Service]
Type=simple
WorkingDirectory=%h/wikidesk
ExecStart=%h/.cargo/bin/wikidesk-server --config %h/wikidesk/config.toml
Restart=on-failure
RestartSec=5

[Install]
WantedBy=default.target
EOF

systemctl --user daemon-reload
systemctl --user enable --now wikidesk
journalctl --user -u wikidesk -f  # check logs

The service is enabled across reboots, but systemd stops user services when the user logs out. To prevent that: loginctl enable-linger $USER

macOS -- launchd
cat > ~/Library/LaunchAgents/com.wikidesk.server.plist << EOF
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key>
  <string>com.wikidesk.server</string>
  <key>ProgramArguments</key>
  <array>
    <string>$HOME/.cargo/bin/wikidesk-server</string>
    <string>--config</string>
    <string>$HOME/wikidesk/config.toml</string>
  </array>
  <key>WorkingDirectory</key>
  <string>$HOME/wikidesk</string>
  <key>RunAtLoad</key>
  <true/>
  <key>KeepAlive</key>
  <true/>
  <key>StandardOutPath</key>
  <string>$HOME/Library/Logs/wikidesk.log</string>
  <key>StandardErrorPath</key>
  <string>$HOME/Library/Logs/wikidesk.log</string>
</dict>
</plist>
EOF

launchctl load ~/Library/LaunchAgents/com.wikidesk.server.plist
tail -f ~/Library/Logs/wikidesk.log  # check logs
Windows -- Task Scheduler
$action = New-ScheduledTaskAction `
  -Execute "$env:USERPROFILE\.cargo\bin\wikidesk-server.exe" `
  -Argument "--config $env:USERPROFILE\wikidesk\config.toml" `
  -WorkingDirectory "$env:USERPROFILE\wikidesk"

$trigger = New-ScheduledTaskTrigger -AtLogOn

$settings = New-ScheduledTaskSettingsSet `
  -AllowStartIfOnBatteries `
  -DontStopIfGoingOnBatteries `
  -RestartCount 3 `
  -RestartInterval (New-TimeSpan -Seconds 10)

Register-ScheduledTask `
  -TaskName "wikidesk" `
  -Action $action `
  -Trigger $trigger `
  -Settings $settings `
  -Description "wikidesk research server"
Docker
docker run -d \
  --name wikidesk \
  --restart unless-stopped \
  -v /path/to/wikidesk:/etc/wikidesk \
  -p 1238:1238 \
  wikidesk-server --config /etc/wikidesk/config.toml

This also provides sandboxing for the research agent.

Logging

wikidesk logs to stderr and defaults to info. Use RUST_LOG for more detail:

RUST_LOG=wikidesk_server=debug,warn wikidesk-server --config config.toml

For systemd, add Environment=RUST_LOG=wikidesk_server=debug,warn under [Service]. For launchd, add the same variable to the plist environment.

Consumer workspace setup

HTTP paths are:

  • GET /wiki -- list configured wikis
  • POST /wiki/{name}/api/research -- submit research over HTTP; request may include local_path for wikilink rendering
  • POST /wiki/{name}/api/sync -- sync a local mirror
  • /wiki/{name}/mcp -- MCP endpoint for that wiki

There are two ways for agents to consume the wiki. Choose one.

Client-server mode (recommended)

Each agent machine runs wikidesk, which communicates with the server over HTTP. The client syncs configured local mirror paths automatically after each research request.

Client-server deployment mode

Install wikidesk

macOS / Linux (pre-built binary)
curl --proto '=https' --tlsv1.2 -LsSf https://github.com/ilya-epifanov/wikidesk/releases/latest/download/wikidesk-installer.sh | sh
Windows (pre-built binary)
powershell -ExecutionPolicy ByPass -c "irm https://github.com/ilya-epifanov/wikidesk/releases/latest/download/wikidesk-installer.ps1 | iex"
From source (any platform with Rust 1.88+)
cargo install wikidesk

Configure and use

# Print a prompt for your coding agent to configure this repo's AGENTS.md/CLAUDE.md.
wikidesk agent setup http://your-server:1238 rlhf rust-notes
# With local path overrides: wikidesk agent setup http://your-server:1238 audio:wiki ml:wiki-ml

export WIKIDESK_SERVER_URL="http://your-server:1238"
export WIKIDESK_WIKIS="rlhf,rust-notes"
# Optional local mirror override syntax: name:relative/path, e.g. audio:wiki,ml:wiki-ml
# Local paths must be relative slash paths with no . or .. components.

# Submit a question to one wiki and sync it
wikidesk research -w rlhf "What is RLHF and how does it relate to DPO?"

# Sync all configured wikis, or one with -w/--wiki
wikidesk sync
wikidesk sync -w rlhf

wikidesk sync refuses to write into an existing directory unless it already has wikidesk's .gitignore marker. Move existing files out of the target path before the first sync.

Mount/symlink mode

Agents connect to the server directly via MCP. The wiki directory is mounted or symlinked into each agent's workspace for read access.

MCP-only deployment mode

Caution: Ensure agents have read-only access to the wiki. Writing directly bypasses the server's research workflow and causes conflicts with concurrent research agents.

Configure MCP

Add wikidesk to your agent's MCP configuration:

claude mcp add wikidesk-rlhf --transport http http://your-server:1238/wiki/rlhf/mcp

Or add it manually to .mcp.json:

{
  "mcpServers": {
    "wikidesk-rlhf": {
      "type": "streamable-http",
      "url": "http://your-server:1238/wiki/rlhf/mcp"
    }
  }
}

The server exposes two MCP tools:

  • research -- Submit a research question. Returns a task_id.
  • get_result -- Poll for the result of a research task. Optionally pass local_path to render wikilinks for a non-default local mirror path.

Mount the wiki (read-only)

Linux / macOS -- symlink
ln -s /path/to/wiki-rlhf/wiki ./wiki-rlhf

Simplest option when the server and agent share a filesystem.

Linux / macOS -- NFS or network mount
# Export on the server (add to /etc/exports):
#   /path/to/wiki-rlhf/wiki  agent-host(ro,no_subtree_check)

# Mount on the agent machine:
sudo mount -t nfs -o ro server-host:/path/to/wiki-rlhf/wiki ./wiki-rlhf
Docker
docker run ... -v /path/to/wiki-rlhf/wiki:/workspace/wiki-rlhf:ro ...

The :ro flag ensures the container cannot write to the wiki.

Podman
podman run ... -v /path/to/wiki-rlhf/wiki:/workspace/wiki-rlhf:ro,Z ...

The Z option handles SELinux relabeling.

Windows -- symbolic link
# Requires Developer Mode or elevated prompt
New-Item -ItemType SymbolicLink -Path .\wiki-rlhf -Target C:\path\to\wiki-rlhf\wiki
Windows -- WSL2
# From within WSL2, the Windows filesystem is at /mnt/c/
ln -s /mnt/c/path/to/wiki-rlhf/wiki ./wiki-rlhf

Configuration reference

Key Default Description
bind_address 127.0.0.1:1238 Top-level HTTP bind address
[[wikis]].name (required) Wiki slug. Derives server repo wiki-{name} (default uses wiki), base path /wiki/{name}, and default client mirror wiki-{name} (default uses wiki).
[[wikis]].description (required) What this wiki covers. Used by MCP descriptions and wikidesk agent setup.
[[wikis]].runner generic Runner type: generic, stream-json, or acp (see below)
[[wikis]].agent_command (required) Command to spawn the research agent. Must contain exactly one $PROMPT element (except for acp runner).
[[wikis]].prompt_template (required) Config-relative path to prompt template file (must contain {question} placeholder)
[wikis.mcp].instructions derived from description Instructions shown to MCP clients
[wikis.mcp].research_tool_description derived from description Custom description for the research MCP tool
[[wikis]].completed_task_ttl_secs 7200 How long to keep completed task results (seconds)
[[wikis]].agent_timeout_secs 1800 Maximum time an agent may run before being killed (seconds)
[[wikis]].research_concurrency 1 Maximum concurrent research agents. Only valid when vcs_workflow is not none; publishing remains serialized.

Runner types

wikidesk supports three runner types for executing research agents. These keys go inside each [[wikis]] table:

generic (default) -- simple stdout capture

Spawns the command, waits for it to exit, and captures stdout as the result. Use --dangerously-skip-permissions in the command.

runner = "generic"
agent_command = ["claude", "-p", "$PROMPT", "--dangerously-skip-permissions"]
stream-json -- Claude Code streaming output

Parses Claude Code's --output-format=stream-json for real-time progress. Extracts text from streaming events and the final result.

runner = "stream-json"
agent_command = ["claude", "-p", "$PROMPT", "--output-format", "stream-json", "--dangerously-skip-permissions"]
acp -- Agent Client Protocol

Uses the Agent Client Protocol for structured communication with claude-agent-acp. This provides richer progress information and proper lifecycle management.

runner = "acp"
agent_command = ["claude-agent-acp"]

Bypass permissions with ACP: Unlike the CLI runners, ACP doesn't accept command-line flags for permissions. Instead, configure bypass mode via Claude's settings file in your wiki repo:

# Create settings file in the wiki repo
mkdir -p wiki-rlhf/.claude
cat > wiki-rlhf/.claude/settings.json << 'EOF'
{
  "permissions": {
    "defaultMode": "bypass"
  }
}
EOF

The ACP runner passes the wiki repo as the working directory, so claude-agent-acp automatically picks up these settings.

Note: Bypass permissions are disabled when running as root unless IS_SANDBOX=1 is set in the environment.

TODO

  • Add simple UI for monitoring research request queues
  • Manage multiple wikis, expose at different base HTTP contexts
  • Add an optional jj workflow with isolated research workspaces and async Git remote sync
  • Support Claude's streaming-json output mode, ACP for better progress monitoring

See also

  • llmwiki-tool -- a companion CLI for wiki maintenance: fixing broken links, renaming pages with reference updates, detecting orphans, and linting against configurable rules

License

Licensed under either of Apache License, Version 2.0 or MIT license at your option.

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in this project by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

from github.com/ilya-epifanov/wikidesk

Установка Wikidesk Server

У этого сервера нет опубликованного пакета — он собирается из исходников. Открой репозиторий и следуй инструкции в README.

▸ github.com/ilya-epifanov/wikidesk

FAQ

Wikidesk Server MCP бесплатный?

Да, Wikidesk Server MCP бесплатный — установка в пару кликов через Unyly без оплаты.

Нужен ли API-ключ для Wikidesk Server?

Нет, Wikidesk Server работает без API-ключей и переменных окружения.

Wikidesk Server — hosted или self-hosted?

Self-hosted: сервер запускается локально на твоей машине командой из раздела установки.

Как установить Wikidesk Server в Claude Desktop, Claude Code или Cursor?

Открой Wikidesk Server на unyly.org, выбери вкладку своего клиента (Claude Desktop, Claude Code, Cursor) и нажми Install — конфиг сгенерируется автоматически, без правки JSON.

Похожие MCP

Compare Wikidesk Server with

Не уверен что выбрать?

Найди свой стек за 60 секунд

Автор?

Embed-бейдж для README

Похожее

Все в категории ai