ReflowPDF

Read a document by its link

get_document

Read-onlyIdempotent

Returns a document made with ReflowPDF (by you, or opened in the editor from your link) as it is now — the person may have edited it in the editor: its source HTML, template data and revision. Read it before changing it with update_document.

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": {
      "document_id": "<document_id>"
    },
    "name": "get_document"
  }
}

Input Schema

Name	Required	Description	Default
`document_id`	Yes	The document_id (or the edit link) from render_pdf, render_template or open_in_editor.

Output Schema

Name	Required	Description
`by`	Yes	Who wrote this revision: you, or the person in the editor.
`data`	Yes
`html`	Yes	The document's source (a template when data is not empty).
`kind`	No	An HTML document (its {{ … }} is text), or a template with its data.
`name`	No
`guest`	No	Printed without an account: the pages carry the ReflowPDF mark.
`owned`	No	The document is the person's account's: your prints of it count to their plan.
`title`	No	The document's title.
`editUrl`	Yes
`previews`	No	Pages as pictures (PNG), kept with the PDF for its day.
`revision`	Yes
`updatedAt`	Yes
`documentId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 11, 2026

addedOutput schema / properties / guest

Added value: +{
+  "description": "Printed without an account: the pages carry the ReflowPDF mark.",
+  "type": "boolean"
+}

addedOutput schema / properties / previews

Added value: +{
+  "description": "Pages as pictures (PNG), kept with the PDF for its day.",
+  "items": {
+    "properties": {
+      "height": {
+        "type": "integer"
+      },
+      "page": {
+        "type": "integer"
+      },
+      "url": {
+        "type": "string"
+      },
+      "width": {
+        "type": "integer"
+      }
+    },
+    "required": [
+      "page",
+      "url",
+      "width",
+      "height"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

addedOutput schema / properties / title

Added value: +{
+  "description": "The document's title.",
+  "type": "string"
+}

First observedOct 26, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: the returned state is live and may have been edited by the person in the editor since it was created, which affects how the agent should trust the revision. No mention of permissions or rate limits.

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?

One sentence that front-loads the return ('Returns a document... as it is now') and folds the freshness caveat and the follow-up action into the same line. The parenthetical is slightly convoluted but no sentence is wasted.

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?

An output schema exists, so return values need no prose, and the annotations carry the safety profile. The description covers freshness and the read-before-write workflow; the only shortfall is not clarifying document-versus-template selection among siblings.

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?

There is a single parameter at 100% schema coverage, and the schema already explains that document_id can be the edit link from render_pdf, render_template or open_in_editor. The description only echoes 'from your link' without adding new syntax or format guidance, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb and resource ('Returns a document made with ReflowPDF') and enumerates what comes back: source HTML, template data and revision. It is concrete enough to separate from update_document, though it never contrasts itself with get_template, the other read-side sibling.

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 an explicit sequencing rule — 'Read it before changing it with update_document' — which tells the agent when this tool must precede a mutation. It stops short of stating when this tool is not appropriate (e.g. reading a template instead of a document).

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

All ReflowPDF tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.