Umtri

Read one wiki page — in full, as an outline, one section, or the lines around a phrase

get_wiki

Returns one wiki page. ref takes either the page slug (what a human says) or the internal id (wiki-) — renaming a page changes its slug but never its id, so ids stay safe to store. Every response carries rev (the current revision, what you pass as baseRev when you write) and bodyChars. By default the whole body comes back. Pages run long (tens of thousands of characters); do not read one in full to answer a small question. view="outline" returns the lead paragraph and the heading tree (path like "1.2", level, heading, line, chars per section) — start there on a page you have not seen. section="" returns just that section (through its sub-headings), plus the footnote definitions it references; it must match exactly one heading, and on an ambiguous match the error lists the candidates with their paths. find="" returns the lines containing the text (case-insensitive, literal) with context lines around each, merged into blocks with line numbers — a block is ready to be the oldString of edit_wiki. find inside one section: pass both. Read in full before write_wiki mode="replace" — it overwrites the body wholesale, and an outline is not the body. For a one-passage fix, find or section the spot and call edit_wiki instead. Pass rev= to read an older revision instead of the current page (list them with list_wiki_revisions; outline/section/find work there too). To put an old revision back, do not paste its body into a write — use write_wiki mode="restore", which cannot mangle the prose in transit.

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

Input Schema

Name	Required	Description
`ref`	Yes	Page slug (e.g. "deploy-notes") or id (wiki-<uuid>).
`rev`	No	Revision number to read. Omit for the current page.
`find`	No	Literal text to look for (case-insensitive). Returns matching lines with context, merged into blocks with line numbers. With section, searches inside that section only.
`slug`	Yes	Ground slug.
`view`	No	"full" (default) returns the body; "outline" returns the lead and the heading tree with sizes instead. Ignored when section or find is given.
`context`	No	Lines of context around each find match. Default 2.
`section`	No	One heading, by its text (case-insensitive; backticks/emphasis ignored) or by its outline path ("1.2"). Returns that section and its sub-sections only.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 6, 2026

TDQS

A4.9/5.0

Behavior5/5

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

With no annotations supplied, the description carries the full behavioral burden and does so: it discloses that every response includes rev and bodyChars, that rev doubles as baseRev for writes, that section must match exactly one heading and the ambiguity error lists candidate paths, and that find results are merged into line-numbered blocks usable directly as oldString. It also warns that write_wiki mode="replace" overwrites the body wholesale while mode="restore" avoids mangling prose in transit.

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?

The purpose sentence is front-loaded and almost every clause carries new information, but the body is a single dense paragraph of roughly 250 words with guidance for four different modes interleaved. Bullets or mode-by-mode grouping would make the section/find versus full-read guidance easier to scan without losing content.

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?

For a 7-parameter read tool with no annotations and no output schema, the description covers what it returns (rev, bodyChars, blocks with line numbers), how each mode behaves, how errors surface, and which sibling to use for writes and revision listing. An agent can select and invoke it correctly without opening anything else.

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

Parameters5/5

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

Despite 100% schema coverage, the description adds meaning the schema lacks: why an id is safer to store than a slug (renaming changes the slug, never the id), what rev means as a write precondition, what outline actually contains (lead paragraph, heading tree with path/level/line/chars), and that find combined with section scopes the search. It clarifies precedence too — view is ignored when section or find is given.

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?

"Returns one wiki page" is a precise verb+resource statement, and the description immediately distinguishes this read tool from edit_wiki, write_wiki, list_wiki and list_wiki_revisions by naming them. The four access modes (full/outline/section/find) are stated so an agent can tell exactly which shape of read it gets.

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?

It gives explicit when-to-use guidance at every fork: start with outline on an unseen page, do not read a long page in full to answer a small question, use section/find plus edit_wiki for a one-passage fix, and read in full only before write_wiki mode="replace". It also routes version listing to list_wiki_revisions and restoration to write_wiki mode="restore", naming the alternative instead of leaving it to inference.

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.