mindyard

Search wiki

search_wiki

Read-only

Find wiki lines containing a case-insensitive text query or regular expression and return page, line, and matched text to locate pages by content.

Instructions

Find the lines of a wiki that contain a text, to locate pages by content.

Returns [{page, line, text}], one entry per matching line. Read the full page with read_page (offset=line jumps to the match); to browse by path, use list_pages. An invalid regular expression is refused with an error.

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": {
      "wiki": "<wiki>",
      "query": "<query>"
    },
    "name": "search_wiki"
  }
}

Input Schema

Name	Required	Description	Default
`wiki`	Yes	Wiki id, as returned by list_wikis.
`query`	Yes	Text to find, case-insensitive.
`regex`	No	Treat query as a regular expression (default: literal).
`scope`	No	Zone: 'wiki' (distilled pages, default), 'raw' (verbatim sources) or 'all' (both). Index, log and schema files sit at the wiki root, outside every zone: open them with read_page.	wiki
`max_results`	No	Stop after this many matching lines.

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.1.3Nov 11, 2026

addedInput schema / properties / max_results / description
```
Added value: +"Stop after this many matching lines."
```
addedInput schema / properties / query / description
```
Added value: +"Text to find, case-insensitive."
```

addedInput schema / properties / regex / description

Added value: +"Treat query as a regular expression (default: literal)."

addedInput schema / properties / scope / description

Added value: +"Zone: 'wiki' (distilled pages, default), 'raw' (verbatim sources) or 'all' (both). Index, log and schema files sit at the wiki root, outside every zone: open them with read_page."

addedInput schema / properties / wiki / description

Added value: +"Wiki id, as returned by list_wikis."

First observedv0.1.1Nov 11, 2026

TDQS

A3.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint and openWorldHint=false, so safety is covered. The description adds genuine context beyond them: the per-matching-line result shape, the regex error behavior, and the read_page offset handoff. It doesn't mention result ordering, truncation behavior when max_results cuts off matches, or case-insensitive matching (left to schema).

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, front-loaded with the purpose, then the return contract, then the routing hints and failure mode. Every clause carries information and none is redundant.

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

Completeness3/5

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

Since an output schema exists, explaining the return shape is optional but helpful. The remaining gap is in behavioral edges that matter for a search tool: no hint on result ordering, pagination, or whether max_results truncation is signaled, and the scope zones are only described in the schema.

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 coverage is 100%, so wiki, query, regex, scope and max_results are already documented in the schema, including the zone semantics the description omits. The description contributes the meaning of the returned line field and its tie to read_page's offset, but adds nothing about the parameters themselves; baseline 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?

States a specific verb and resource ("Find the lines of a wiki that contain a text") plus the higher-level goal (locate pages by content), which distinguishes it from read_page and list_pages without needing to open any schema.

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?

Explicitly routes the agent to alternatives: read_page for full content with offset=line to jump to a match, list_pages for browsing by path. It also notes schema/log files sit outside the zones and must be opened with read_page, a useful exclusion. No explicit "when not to use" statement, so it stops short of a 5.

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

Deploy Server