mindyard

List pages

list_pages

Read-only

Browse a wiki's structure by listing Markdown page paths for a chosen zone, with optional prefix filtering and a result limit; use it to locate pages before opening one by path.

Instructions

List the Markdown files of a zone, to browse a wiki by its structure.

To find pages by their content, use search_wiki instead; to open one, pass its path to read_page. Returns {pages, truncated, total}: paths relative to the wiki root, sorted and capped at limit; total counts every match and truncated says the list was cut.

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>"
    },
    "name": "list_pages"
  }
}

Input Schema

Name	Required	Description	Default
`wiki`	Yes	Wiki id, as returned by list_wikis.
`limit`	No	Maximum number of paths returned.
`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
`prefix`	No	Keep only paths starting with this, relative to the wiki root, e.g. 'wiki/people/'. Empty: no filter.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv0.1.3Nov 11, 2026

addedInput schema / properties / limit / description

Added value: +"Maximum number of paths returned."

addedInput schema / properties / prefix / description

Added value: +"Keep only paths starting with this, relative to the wiki root, e.g. 'wiki/people/'. Empty: no filter."

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

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds sorting, the limit cap, and the fact that total counts every match while truncated flags a cut list. It also warns that index, log and schema files live at the wiki root outside every zone — a real behavioral caveat an agent would otherwise miss. It stops short of pagination/continuation guidance, so not a 5.

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

Conciseness4/5

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

Front-loaded with purpose, then routing, then return shape — no wasted sentences. The return-shape sentence is slightly redundant given an output schema exists, which keeps it from a 5.

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

Completeness5/5

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

With annotations covering the read-only profile, a fully described 4-parameter schema, and an output schema carrying the return contract, nothing an agent needs to invoke this correctly is missing. The zone caveat closes the one non-obvious trap.

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 wiki, limit, scope and prefix are already fully documented with defaults and an example. The description only restates that results are capped at limit and paths are relative to the wiki root, adding marginal meaning. 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 ('List the Markdown files of a zone') plus the intent ('browse a wiki by its structure'), which separates it cleanly from search_wiki (content lookup) and read_page (open a single page). An agent can pick this tool without opening 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 Guidelines5/5

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

Explicitly names both alternatives and the condition that selects each: search_wiki for finding by content, read_page for opening a path. The structural-browsing framing gives the when-to-use case directly.

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

Deploy Server