Problem
codedb_remote today hits codedb.codegraff.com only. That backend is the WASM-on-Workers indexer with actions tree | outline | search | meta. Its sibling project codedb-cloud / wiki.codes is a Zig-native router on Hetzner with parquet-backed cold + hot tiers, and it offers a superset of useful actions — notably symbol (exact-identifier lookup) and policy (hot-pin size class) — plus more repos indexed and richer result shapes.
Agents calling codedb today have no way to reach wiki.codes. Forcing a separate MCP server for it would double the install footprint and fracture the "codedb_remote" mental model.
Proposal
Add a backend parameter to the existing codedb_remote tool. Default preserves current behavior.
```
codedb_remote repo="rust-lang/rust" action="symbol" query="HashMap" backend="wiki"
codedb_remote repo="vercel/next.js" action="tree" backend="wiki"
codedb_remote repo="justrach/merjs" action="search" query="handleRequest" # still codegraff
```
| action |
codegraff (default) |
wiki |
| tree |
✓ |
✓ |
| outline |
✓ |
✓ |
| search |
✓ |
✓ |
| meta |
✓ |
✗ (not in router.zig) |
| symbol |
✗ |
✓ (new) |
| policy |
✗ |
✓ (new) |
URL shape
Slug derivation: `owner/repo` → `owner-repo` (matches the naming wiki.codes produces on ingest: e.g. `rust-lang/rust` → `rust-lang-rust`, `vercel/next.js` → `vercel-next-js`).
Validation
- `backend` ∈ `{"codegraff","wiki"}`, default `"codegraff"`
- When `backend="wiki"`: reject `action="meta"` with a clear error
- When `backend="codegraff"`: reject `action="symbol"|"policy"`
- Same repo-format + path-traversal validation as today
Why bundle here instead of a separate MCP server
- One `codedb_remote` namespace means agents don't need to know which service a repo is indexed on — they just pick the backend.
- Shares the existing curl + error handling.
- ~80 lines of Zig in `src/mcp.zig`, one new handler branch, no new dependencies.
Out of scope for this issue
- Auto-failover between backends (e.g. codegraff 404 → try wiki). Leave as a follow-up if agents want a single "best effort" mode.
- Writing to wiki (indexing a new repo). wiki exposes `/admin/ingest` but that's authenticated — bundling it would mean exposing a token to the agent. Keep read-only.
- Swapping the default backend. Current callers stay on codegraff unless they opt in.
Test plan
- `codedb_remote repo="rust-lang/rust" action="symbol" query="HashMap" backend="wiki"` → 25 hits, includes `library/std/src/collections/hash/map.rs:247`
- `codedb_remote repo="justrach/merjs" action="search" query="handleRequest"` (codegraff default) → unchanged
- `codedb_remote repo="x" action="meta" backend="wiki"` → clear error "action meta is not supported on the wiki backend"
Problem
codedb_remotetoday hitscodedb.codegraff.comonly. That backend is the WASM-on-Workers indexer with actionstree | outline | search | meta. Its sibling project codedb-cloud / wiki.codes is a Zig-native router on Hetzner with parquet-backed cold + hot tiers, and it offers a superset of useful actions — notablysymbol(exact-identifier lookup) andpolicy(hot-pin size class) — plus more repos indexed and richer result shapes.Agents calling codedb today have no way to reach wiki.codes. Forcing a separate MCP server for it would double the install footprint and fracture the "codedb_remote" mental model.
Proposal
Add a
backendparameter to the existingcodedb_remotetool. Default preserves current behavior.```
codedb_remote repo="rust-lang/rust" action="symbol" query="HashMap" backend="wiki"
codedb_remote repo="vercel/next.js" action="tree" backend="wiki"
codedb_remote repo="justrach/merjs" action="search" query="handleRequest" # still codegraff
```
URL shape
Slug derivation: `owner/repo` → `owner-repo` (matches the naming wiki.codes produces on ingest: e.g. `rust-lang/rust` → `rust-lang-rust`, `vercel/next.js` → `vercel-next-js`).
Validation
Why bundle here instead of a separate MCP server
Out of scope for this issue
Test plan