wikijs-graphql-mcp
Related Servers
Alternatives to wikijs-graphql-mcp
No user-submitted related servers found.
Related Servers
- AlicenseBqualityDmaintenanceEnables AI assistants to search and retrieve content from WikiJS knowledge bases, allowing integration with your Wiki through simple search and retrieval tools.430 npm6MIT
- AlicenseNot gradedqualityDmaintenanceEnables AI assistants to search, retrieve, and optionally edit pages in a WikiJS knowledge base via the Model Context Protocol.36 npm1MIT
- FlicenseNot gradedqualityNot gradedmaintenanceEnables comprehensive management of WikiJS instances through tools for searching, creating, updating, and deleting wiki pages. It supports advanced features like knowledge graph exploration, page summaries, and content exporting for documentation workflows.-
- FlicenseNot gradedqualityBmaintenanceEnables MCP clients to interact with a Wiki.js 2.x instance via its GraphQL API, allowing page listing, reading, full-text search, creation, updating, and deletion, with a read-only mode and robust path handling.-
- AlicenseAqualityBmaintenanceEnables MCP clients to search, read, and edit Wiki.js pages, and manage assets, comments, users, groups, and maintenance jobs through the Wiki.js GraphQL API.6279 npm3MIT
- AlicenseNot gradedqualityCmaintenanceProvides read-only access to an unofficial student wiki, enabling course catalog browsing, study-page navigation, Markdown page and discussion reading, full-text search, attachment and PDF retrieval, local OCR, and image handoff for client vision models without modifying the wiki.1MIT
TDQS
Scored across 6 tools
Each tool has a reasonably distinct role, but list_pages, search_pages, and browse_tree all enumerate pages and their boundaries depend on the descriptions rather than the names. The get_page vs get_page_by_id pair is only distinguished by path-vs-ID, which is clear enough once read but easy to misselect at a glance.
Every tool carries the wikijs_ prefix and a verb_noun form (search_pages, list_pages, list_tags, get_page, get_page_by_id), so the set reads predictably. Minor deviations: browse_tree uses a different verb style, and get_page/get_page_by_id are near-duplicates in name shape.
Six tools is well within the ideal range and each covers a distinct read path (search, fetch by id, fetch by path, list metadata, tree browse, tags). Nothing feels padded or redundant.
The surface is entirely read-only — there is no create, update, move, or delete page operation, so any agent asked to author or maintain wiki content will hit a dead end. Tag listing without any tag-mutation or page-write tool reinforces that this is a partial lifecycle.