ReflowPDF

Keep an image for a document

upload_image

Idempotent

Keeps an image and returns its link, to use as or CSS url() in render_pdf, render_template, open_in_editor and update_document — so the document stays small when you read it back. Give one of: image — a picture the person attached in the chat, as your client passes attached files to tools; image_base64 — bytes you have yourself (one you made, a small file you can read: base64 is text you write, so tens of KB). PNG, JPEG, HEIC, GIF, WebP or AVIF; a photo over 10 MB or in HEIC is brought to print size (4096 px on the long side). A picture the person attached that you can see but have no file of: call ask_for_images, which gives them a link to upload it from their device. An image at a public https address needs no upload: use that address. An SVG goes into the HTML as it is. The image lasts 30 days after a document using it last changed.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "upload_image"
  }
}

Input Schema

Name	Required	Description	Default
`image`	No	A picture the person attached in the chat.
`image_base64`	No	The image's bytes, base64 (a data: URI is taken too).

Output Schema

Name	Required	Description
`url`	Yes	The image's link, for <img src>.
`type`	Yes
`bytes`	Yes
`width`	Yes	Pixels (0: not read from this format).
`height`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 27, 2026

addedInput schema / properties / image

Added value: +{
+  "additionalProperties": true,
+  "description": "A picture the person attached in the chat.",
+  "properties": {
+    "download_url": {
+      "description": "A temporary https address of the file.",
+      "type": "string"
+    },
+    "file_id": {
+      "type": "string"
+    },
+    "file_name": {
+      "type": "string"
+    },
+    "mime_type": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "download_url",
+    "file_id"
+  ],
+  "type": "object"
+}

removedInput schema / required
```
Removed value: -[
-  "image_base64"
-]
```

First observedOct 26, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint=false, idempotentHint=true), the description discloses that a photo over 10 MB or in HEIC is downscaled to 4096 px, which formats are accepted, and that the image persists 30 days after the last document using it changed. That is exactly the non-obvious lifecycle and transformation behavior an agent needs before storing user data.

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?

Front-loaded with purpose and return value, and every clause carries information (formats, downscaling, retention, alternatives). It is a single dense paragraph with heavy em-dash use, though, so the alternatives and format list are harder to scan than they need to be.

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 two-parameter write tool with nested object input and an output schema, the description covers the input tradeoffs, the transformation rules, the substitution paths, and the retention window. Nothing an agent needs to call it correctly is missing.

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

Parameters5/5

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

Schema coverage is already 100%, but the description adds real meaning: it frames the two inputs as a choice ('Give one of'), explains what 'image' actually is (a client-passed attachment object), and gives a practical sizing heuristic for base64 ('tens of KB', text you write). This goes well past the schema's own field 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?

States a specific verb and resource ('Keeps an image and returns its link') and immediately names the downstream consumers (render_pdf, render_template, open_in_editor, update_document) plus the reason ('so the document stays small when you read it back'). It also distinguishes itself from ask_for_images and from the no-upload case of a public https URL.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit routing rules: use the `image` object for chat attachments, `image_base64` for bytes you hold (small files), call ask_for_images for an attachment you can see but have no file of, and skip upload entirely for a public https address or an SVG. These are genuine when-to-use and when-not-to-use exclusions against named siblings.

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.