Umtri

List wiki pages of a ground

list_wiki

Lists the ground's wiki — the prose the tree cannot hold: conventions, decisions and why they were made, glossary, onboarding. Reference entries describing how things work, not a log of what happened: the change record is list_events, the page's own past is in its revisions. Not the structure itself (get_graph) and not defects (list_bugs). Bodies come back as 200-char excerpts by default so a scan stays cheap; pass body="full" only when you mean to read them, or body="none" for a pure index. A page may hang off a node (nodeId) or float free — pass node= for one node's pages, or node="none" for the pages not yet attached to anything, which is the list worth reviewing when the tree has grown. The wiki is a tree: each page has a parent page and a position among its siblings, starting from an overview page. order="tree" returns the whole table of contents in reading order (depth-first, with depth) — use it to read the wiki front to back or to see where a new page belongs. Every page also has a kind (overview / concept / component / rule / glossary); kind="none" lists the pages not yet classified.

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": {
      "slug": "<slug>"
    },
    "name": "list_wiki"
  }
}

Input Schema

Name	Required	Description
`body`	No	How much body text per page. Default "excerpt" (200 chars).
`kind`	No	Only pages of this kind, or "none" for unclassified pages. Omit for all.
`node`	No	Node id to filter by, or "none" for pages attached to nothing yet. Omit for all.
`slug`	Yes	Ground slug.
`limit`	No
`order`	No	"desc" (default) / "asc" by last update, or "tree" for the table of contents in reading order.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 6, 2026

TDQS

A4.6/5.0

Behavior4/5

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

With no annotations supplied, the description carries the full burden and does substantial work: it discloses the 200-char excerpt default, that tree order is depth-first and includes depth, and that all pages form a parent/position tree rooted at an overview page. It never states permissions/auth needs or how limit interacts with tree ordering, which leaves a gap for a 6-parameter list tool with zero annotation coverage.

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?

Purpose is front-loaded in the first clause and every sentence carries routing or parameter information; nothing is filler. The single dense paragraph is somewhat run-on, with the exclusion list packed mid-sentence, which costs a little scannability.

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?

No output schema and no annotations, yet the description explains return shape (excerpts vs. full bodies, depth in tree order) and covers five of six parameters meaningfully. The only omission is limit/pagination, which is minor for a filtered listing tool.

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

Parameters4/5

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

Schema coverage is high (83%), so the baseline is 3, and the description adds real meaning on top: the rationale for each body mode, what "tree" returns (table of contents in reading order with depth), and the modeling concept behind node="none" and kind="none". It only falters on limit, which is neither documented in the schema nor explained here.

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 ("Lists the ground's wiki") and immediately defines the scope of what counts as a wiki page vs. a change record, revision, tree structure, or bug. It explicitly names the siblings it is not (list_events, get_graph, list_bugs), so an agent can route 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?

Gives concrete when-to-use conditions tied to parameter choices: body="full" only when you mean to read bodies, body="none" for a pure index, order="tree" to read front to back or place a new page, node="none" to review unattached pages. It also routes alternatives explicitly (change history to list_events, a page's past to its revisions).

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

All Umtri tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.