Skip to main content
Glama
Sign In

pdfedit-mcp

by io.github.zp130221
OverviewDiscussionsAdmin

Batch-edit a PDF template

pdf_batch
Idempotent

Apply the same edits to one template PDF once per record, producing one output document per record — a mail merge over an existing PDF. Returns a job_id: call pdf_job with it for the per-record results. To change text on one page only, set scope.pages; to pick one of several identical matches, use scope.after with nearby text or scope.occurrence. Use op: 'redact' when the text must be unrecoverable.

Input Schema

NameRequiredDescriptionDefault
fileYesThe PDF: an absolute (or ~) local path, which this server uploads for you, an https:// URL the API fetches, or an `f_…` file id from an earlier call. Used as the template for every record.
editsYesThe edits applied to each record, with `{field}` placeholders filled from it.
optionsNo
recordsNoOne object per output document.
passwordNo
records_urlNoA CSV or JSONL file of records, instead of `records`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / edits / items / properties / op / enum
      Previous value: -[
-  "replace",
-  "delete",
-  "redact",
-  "insert",
-  "form",
-  "stamp"
-]New value: +[
+  "replace",
+  "delete",
+  "redact",
+  "insert",
+  "form",
+  "stamp",
+  "remove_image"
+]
  2. Changed3 schema fields changed
    • addedInput schema / properties / edits / items / properties / box
      Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": false,
+      "properties": {
+        "h": {
+          "description": "Height in points.",
+          "maximum": 14400,
+          "type": "number"
+        },
+        "page": {
+          "maximum": 9007199254740991,
+          "minimum": 1,
+          "type": "integer"
+        },
+        "w": {
+          "description": "Width in points.",
+          "maximum": 14400,
+          "type": "number"
+        },
+        "x": {
+          "description": "Left edge, points from the page's left.",
+          "minimum": 0,
+          "type": "number"
+        },
+        "y": {
+          "description": "Top edge, points from the page's TOP.",
+          "minimum": 0,
+          "type": "number"
+        }
+      },
+      "required": [
+        "h",
+        "page",
+        "w",
+        "x",
+        "y"
+      ],
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ]
+}
    • addedInput schema / properties / edits / items / properties / image
      Added value: +{
+  "description": "The image to place: PNG, JPEG, GIF, BMP or WebP, as base64 (a `data:` URL is accepted). JPEG is stored as sent; PNG keeps its transparency.",
+  "type": [
+    "string",
+    "null"
+  ]
+}
    • changedInput schema / properties / edits / items / properties / op / enum
      Previous value: -[
-  "replace",
-  "delete",
-  "redact",
-  "insert",
-  "form"
-]New value: +[
+  "replace",
+  "delete",
+  "redact",
+  "insert",
+  "form",
+  "stamp"
+]
  3. Changed1 schema field changed
    • addedInput schema / properties / options / properties / webhook_url / description
      Added value: +"Called with POST when the job finishes: the body is the job's result (what GET /v1/jobs/{id} returns) plus `event` (job.done, job.failed, batch.done ...) and `job_id`, signed in `X-Signature` (hex HMAC-SHA256 of the raw body with the account's webhook secret). Non-2xx answers are retried after 1, 5 and 30 minutes. https only."
  4. 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 idempotent, non-destructive, open-world behavior, so the description only needs to add flow and risk context — which it does: an async job handle, a required follow-up call, and the warning that redaction (irreversible) is the choice when text must be unrecoverable. It does not mention options that change behavior materially (dry_run, preview, atomic, output zip/files, webhook).

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

Conciseness5/5

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

Four sentences, front-loaded with the core definition, then the job handoff, then scoping hints. No filler, and each sentence maps to a decision the caller must make.

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

Completeness3/5

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

The core workflow and return path are covered, but for a tool with 6 params, deep nested edit objects, and a 20+ field options object, the description never mentions the records vs records_url alternative, dry_run/preview for validation, or output zip vs files. Those gaps matter given there is no output schema.

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 67%, and the description fills the most important gap: scope.after and scope.occurrence carry no schema descriptions but are explained here as disambiguators for duplicate matches, along with scope.pages for page limiting. It leaves records vs records_url and most of options undocumented.

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+resource with scope: apply the same edits to one template once per record, producing one output per record. The 'mail merge over an existing PDF' framing separates it cleanly from the single-document sibling pdf_edit without requiring 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 clear operational context: it returns a job_id and pdf_job must be called for per-record results, and it names the conditions that select scope.pages vs scope.after/occurrence vs op:'redact'. It stops short of explicitly contrasting with pdf_edit/pdf_preview, so no exclusion guidance.

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

All pdfedit-mcp toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources