The operational facts an agent needs when authoring wiki content through the MCP servers. The definitive tool registry is the live server (McpServerInitializer / KnowledgeMcpInitializer); verify counts there before editing docs that state them.
/wikantik-admin-mcp) — authoring and analytics: write_pages, update_page, rename_page, delete_pages, mark_page_verified, verify_pages, read_page, preview_structured_data, list_retrieval_queries, link/orphan/statistics tools, KG curation./knowledge-mcp) — read-only retrieval: assemble_bundle (the live retrieval gate), retrieve_context, read_pages, structural listing tools (list_clusters, list_pages_by_filter, list_tags, list_metadata_values), KG query tools, get_briefing.MCP_RATE_LIMIT_PER_CLIENT, global cap 500/s). Modest parallelism is fine now; a genuinely tight loop still 429s — back off ~1s on 429.update_page requires expectedContentHash from read_page. On drift you get {updated:false, currentHash, latestContent} — rebase and retry without a new read. Background processes (the structural spine maintaining hubs: frontmatter) can move the hash between your read and write; this is normal.update_page metadata merges onto existing frontmatter — a one-field edit never wipes the rest; content (body) replaces wholesale and may be omitted for metadata-only edits.write_pages fails pages that already exist — use update_page for those; per-page results let you retry only failures.Main.md is generated from Main.pins.yaml and CI reverts hand-edits.type: runbook requires a structured runbook: block (when_to_use / steps / pitfalls) or validation rejects the page.Discover (list_*, search) → write (write_pages/update_page) → lint (verify_pages with retrieval_readiness+seo_readiness) → live-check (assemble_bundle) → optionally ping_search_engines (IndexNow; Google needs manual GSC).