Skip to main content
Glama
wikijs-graphql-mcp

wikijs-graphql-mcp

by vanisoul

搜尋 Wiki.js 頁面

wikijs_search_pages
Read-onlyIdempotent

Search Wiki.js pages by keyword to get titles, descriptions, and paths, optionally limited by path prefix; use the returned paths to read full page content.

Instructions

以關鍵字搜尋 Wiki.js 頁面(使用站台設定的搜尋引擎),回傳標題、描述與路徑(不含頁面 ID,因站台搜尋索引的 ID 可能與實際頁面不一致)。可用 pathPrefix 限定路徑範圍;取得路徑後再以 wikijs_get_page 讀取全文。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "wikijs_search_pages"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNo回傳筆數上限,預設 20
queryYes搜尋關鍵字
localeNo頁面語系,例如 zh-tw;省略時使用 WIKIJS_LOCALE(預設 zh-tw)
offsetNo略過前幾筆結果,用於分頁,預設 0
pathPrefixNo只保留此路徑底下的頁面,例如 RD部/Projects(以路徑段落比對,不分大小寫)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description adds genuinely new behavior: results come from the site-configured search engine, the returned fields are limited, and the page ID is deliberately omitted because search-index IDs may diverge from real page IDs. That ID caveat is an important operational trait not derivable from annotations or schema, though result ordering and pagination behavior beyond offset remain unstated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences with no filler: purpose and return shape first, then the ID caveat, then the pathPrefix option and the follow-up call. The most decision-relevant information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by enumerating returned fields and warning about the missing ID, which is what an agent needs to chain to wikijs_get_page. It stops short of describing result ordering or relevance semantics, a minor gap for a search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter (query, limit, offset, locale, pathPrefix) is already documented, including the pathPrefix example and locale fallback. The description only restates that pathPrefix limits path scope, adding no syntax or matching detail beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource ('以關鍵字搜尋 Wiki.js 頁面') and lists exactly what is returned: title, description, and path. It also distinguishes itself from siblings by noting that no page ID is returned and that wikijs_get_page must be used to read the full text, which implicitly steers the agent away from wikijs_get_page_by_id.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states a clear two-step workflow: search here, then call wikijs_get_page with the returned path, and explains when pathPrefix is useful for narrowing scope. It does not explicitly say when to prefer wikijs_list_pages or wikijs_browse_tree over keyword search, so the alternative-selection guidance is incomplete rather than absent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.