Skip to main content
Glama

get_page

Fetch one Markdown page by id. Returns its body, its revision — pass that as baseRevision when replacing the whole body — its language, who edited it last, and its URL in the app, which only members of this workspace can open.

Instructions

Fetch one Markdown page by id. Returns its body, its revision — pass that as baseRevision when replacing the whole body — its language, who edited it last, and its URL in the app, which only members of this workspace can open. To let somebody outside the workspace read it, a person in the workspace opens the page in DiagramZu and uses its Share button, which mints a public read-only link. For a long document prefer outline: true (the heading tree, with an anchor per heading) and then section: '<heading text or anchor>' for just the part you need.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesPage UUID
spaceNoWhich workspace to act in: its id, its slug, or its exact name (case-insensitive). Omit to use this token's default workspace. Call list_spaces to see what this token can reach. A name that matches more than one workspace is refused — pass the id or slug instead.
outlineNoReturn only the heading tree — level, text and an anchor per heading — instead of the body. Use this first on a long page, then ask for one section.
sectionNoReturn only one section: a heading's exact text, or the anchor that `outline` printed for it. The section runs from that heading to the next heading of the same or a higher level, so sub-headings come with it. A heading text that fits more than one heading is refused — pass its anchor instead.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.0.8

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the burden of disclosure and does so well: it describes the returned body, revision, language, last editor, and app URL, plus the workspace-access restriction and the revision reuse pattern. It does not explicitly state that the call is read-only or what permissions are required beyond workspace membership, which keeps it from 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?

The description is front-loaded with purpose and return details, then gives useful outline/section guidance. The sentence explaining how a human uses the Share button is somewhat tangential to invoking get_page, but the overall structure is efficient and readable.

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 no output schema and no annotations, the description fully covers what an agent needs: return fields, revision handling, access scope, and the outline/section workflow for long pages. Nothing essential for correct invocation is missing.

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 description coverage is 100%, so parameter documentation is already strong. The description adds meaningful usage semantics for `outline` and `section` by recommending a long-document workflow and explaining that revision should be passed as `baseRevision` when replacing the body.

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 states a specific verb and resource: 'Fetch one Markdown page by id.' It clearly distinguishes the operation from sibling tools like get_diagram, get_version, and list_pages by identifying both the object and the access method.

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 explicit guidance for long documents: prefer `outline: true`, then `section` for just the needed part. It also explains the workspace access context and how external sharing works. However, it does not explicitly compare this tool to alternatives like list_pages or get_version when deciding which tool to select.

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