Kaiku

get_wiki_page

Get one wiki page by id, or by space key + title, if it is visible to this token. Returns the page text, its labels, its parent and child pages, its comments, and the issues linked to it. Pass withMarkdown: true when you intend to edit it — you then get the page's Markdown source to change and hand back to update_wiki_page, and each comment's own Markdown, version and anchor for update_wiki_comment. A large page is read a part at a time: 'outline' lists its headings and how big each section is, then 'section' returns one of them (or 'offset'/'limit' a run of lines), and update_wiki_page's 'edits' changes just the words you mean without sending the page back.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	No	Page id (as returned by search_wiki).
`limit`	No	How many lines to return from 'offset' (default 200).
`title`	No	Exact page title, when looking the page up by title.
`offset`	No	Return only the Markdown source from this 1-based line on — for a page without headings to navigate by. Pair with 'limit'.
`outline`	No	Return the page's table of contents instead of its body: per heading its level, text, anchor, the 1-based lines its section spans in the Markdown source, and its size in characters. Start here on a large page.
`section`	No	Return only this section's Markdown — its heading line down to the next heading of the same or a higher level, subsections included. Name it by its anchor (as 'outline' gives it: the id a {toc} entry links to) or by its heading text.
`spaceKey`	No	Space key, when looking the page up by title.
`withRelated`	No	With 'outline', 'section' or 'offset': also return the page's children, attachments, comments and linked issues, which a partial read otherwise leaves out.
`withMarkdown`	No	Return the Markdown source ('markdown') instead of the plain text — what to edit and pass back to update_wiki_page, and, for each comment, to update_wiki_comment. Off by default: reading costs less as text.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 22, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and meets it: token-visibility filtering, default plain-text vs Markdown mode, comment metadata needed for update_wiki_comment, and the partial-read semantics for large pages. It also notes the performance tradeoff ('reading costs less as text') without contradicting any annotation.

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?

Four dense, purposeful sentences with the core purpose and lookup modes front-loaded. Every sentence earns its place, and the parenthetical clarifications resolve schema-level ambiguities such as how anchors are named and what the default limit is.

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 9-parameter read tool with no output schema and no annotations, the description covers the full decision path: what it fetches, when to choose Markdown, how to navigate large pages, and how partial reads interact with update_wiki_page. No essential calling behavior is left undocumented.

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?

The input schema already documents all 9 parameters at 100% coverage, so the baseline is 3. The description adds relational workflow meaning: start with outline, then section or offset/limit, and enable withMarkdown only when edits are intended. This goes beyond restating the schema without duplicating it.

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 opens with a specific verb and resource: 'Get one wiki page by id, or by space key + title', and then enumerates what is returned: text, labels, parent/child pages, comments, and linked issues. It also distinguishes itself from update_wiki_page by describing the edit handoff workflow, so an agent can tell the read operation apart from its siblings.

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 gives clear context: use this for reading a page, pass withMarkdown when preparing to edit, and use outline/section/offset/limit for partial reads of large pages. It does not explicitly state when to prefer sibling tools like search_wiki or get_comments, so it stops just short of full when-to-use/when-not-to-use guidance.

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

All Kaiku 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.

Resources

Need Help?