Skip to main content
Glama

Make one document, or several, into pages, put their pages in order, or take them back out

page_doc

Hangs a document under another as one of its pages, detaches a page back into a standalone document, or reorders a document's existing pages in one call.

Instructions

Needs doc, or order with page_of. A page is real content related to one subject but not part of it — a runbook, a contract, an annex — never a session: a review, a day's progress or a PR's notes belong on the task. Hang a document from another as one of its pages, or take a page out by leaving page_of out, which makes it a document of its own again, back in the folder it came from. A page goes with its document everywhere — folder, archive and deletion — and holds no pages of its own. Hanging one writes the line that names it at the end of that document, the same line write_doc with page_of writes; after, before and at say where that line goes instead. Taking a page out writes nothing: the line stays where it was, now pointing at a document of its own, and taking it out of the text is yours to do. order is the third thing this does: it takes the pages of one document and deals the lines they already have back out in the order you name, which is how several are put in order in one call. The order pages are read in is the order their lines sit in the document, and nothing else. The line is ![Its title](tisty:doc/its-name), opening bang and all — without it the line is a mention in a sentence and gives the page no place — and a square bracket in the title goes in with a backslash before it.

Input Schema

NameRequiredDescriptionDefault
atNoWhere to write the line when you are not naming a page to sit beside: "first" puts it before every page the document names, "last" after them all. It is what to send for a document whose pages no line names yet, since there is no page there to name
docNoThe id of the document to hang or to take out, as `docs` hands it back — an opaque name like `q7ntmzbm-0001`, not its title. A list of ids does the same to all of them in one go, and if one of them cannot, none of them moves.
afterNoThe id of another page of that same document. The line naming this page is written straight after the line naming that one, which is what puts it next in reading order. Needs `page_of`, takes one `doc`, and the page you name has to have a line already
orderNoThe pages of one document, by their ids, in the order they are to be read. Their lines are moved into each other's places and nothing else in the text moves, so pages you leave out stay where they are. Two or more ids, each named once. Needs `page_of`, and goes on its own: no `doc`, `after`, `before` or `at` — one call says an order, another puts one page somewhere. Every page it names has to have a line of its own already
beforeNoThe same, on the other side: the line goes straight before the one naming this page
page_ofNoThe id of the document it becomes a page of — an opaque name like `q7ntmzbm-0001`, not its title. Leave it out to make it a document of its own

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so thoroughly: it explains that pages move with their parent document through folder, archive, and deletion; that pages cannot have pages of their own; that hanging writes a line while taking out writes nothing; and that ordering only rearranges existing lines. It also discloses the exact line syntax and escaping rules.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The necessary information is present and the first sentence front-loads the core dependency, but the description is a long, dense block with convoluted phrasing and some repetition. It would be easier to use if structured into explicit sections for attach, detach, and order.

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 complex six-parameter tool with no annotations and no output schema, the description covers prerequisites, side effects, ordering semantics, line format, and interaction with sibling tools such as `write_doc`. Nothing essential for correct invocation appears to be missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents the parameters in detail. The description reinforces the main dependency pattern (`doc`, or `order` with `page_of`) and explains `after`/`before`/`at` behavior, but adds little beyond the schema's own parameter descriptions.

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 specific operations: hanging a document as a page, taking a page out, and ordering pages. It also distinguishes a page from a session/task and from a normal document, so an agent can identify the tool 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?

It clearly says what qualifies as a page and explicitly excludes sessions, reviews, progress, and PR notes, routing those to the task instead. It does not give a full sibling-by-sibling decision tree, but the main when/when-not boundary is explicit.

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