Skip to main content
Glama

Get wiki page

get_wiki_page
Read-only

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. A page with manim code blocks (where the company has scenes switched on) also returns 'scenes': each block's drawing state — queued, rendering, done or failed — manim's own error when it failed, and the attachment it was drawn into. A page with anim blocks (a scene as JSON the reader's client plays itself, no rendering) returns 'anims': for each, whether it can be shown, its length, or every problem with where it stands.

Input Schema

NameRequiredDescriptionDefault
idNoPage id (as returned by search_wiki).
limitNoHow many lines to return from 'offset' (default 200).
titleNoExact page title, when looking the page up by title.
offsetNoReturn only the Markdown source from this 1-based line on — for a page without headings to navigate by. Pair with 'limit'.
outlineNoReturn 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.
sectionNoReturn 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.
spaceKeyNoSpace key, when looking the page up by title.
withRelatedNoWith 'outline', 'section' or 'offset': also return the page's children, attachments, comments and linked issues, which a partial read otherwise leaves out.
withMarkdownNoReturn 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.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare read-only, non-destructive and closed-world, yet the description still adds real behavior: token-scoped visibility, the full set of side data returned (labels, parents, children, comments, linked issues), the text-vs-Markdown cost tradeoff, and the partial-read model. It omits what happens when the page is missing or invisible (error vs empty), which is the one behavioral fact an agent would still want.

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 and lookup modes are front-loaded in the first sentence, and every subsequent sentence carries information. However, it is a single dense block, and the ```manim/```anim sentences are niche relative to core read behavior, slightly overweighting the tail.

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

Completeness4/5

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

With no output schema, the description must carry the return shape, and it does so in detail down to scene states and anim validity. Minor gap: core fields are enumerated only in passing, and no error/no-access behavior is described, so an agent still has unknowns at the edges.

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 100%, so the baseline is 3, but the description adds cross-parameter meaning the schema does not: it chains outline → section → offset/limit as a paging strategy and implies withRelated must be set on partial reads to keep children/comments. That interaction guidance is genuine added value.

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 (get one wiki page) plus both lookup keys (id, or spaceKey + title) and the visibility condition that governs the result. An agent can distinguish it from search_wiki (find) or get_wiki_page_reading (read state) without opening the 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?

Gives explicit conditional guidance: use withMarkdown when you intend to edit, and the returned Markdown is what you hand to update_wiki_page / update_wiki_comment. It also implies the outline-then-section strategy for large pages. It stops short of naming exclusion cases, such as when to prefer search_wiki or get_linked_confluence_page instead.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources