Skip to main content
Glama
Sign In
pdfops-mcp

pdfops-mcp

Official
by pdfops
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Generate invoice PDF

pdf_invoice
Idempotent

Generate a professional invoice PDF directly from structured invoice data—no template needed. Output can be saved to a file or returned inline.

Instructions

Generate a complete, professionally laid-out invoice PDF from structured data — no template needed. Deterministic: the same input produces byte-identical output (safe to re-run). Note: without a paid PDFops key the output carries a small "Generated with pdfops.dev" footer line. Returns the invoice written to output_path, or inline as an application/pdf resource when output_path is omitted; an existing file at output_path is overwritten. Use this when you have invoice DATA and no document; if you already have an invoice PDF or a fillable template to populate, use pdf_fill instead.

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": {
      "invoice": "<invoice>"
    },
    "name": "pdf_invoice"
  }
}

Input Schema

NameRequiredDescriptionDefault
invoiceYesInvoice data
output_pathNoAbsolute path to write the result. Omit when running remotely: the PDF is then returned inline as an application/pdf resource for the client to save.

Output Schema

NameRequiredDescriptionDefault
bytesYesSize of the produced PDF in bytes
output_pathNoAbsolute path written, when output_path was supplied
resource_uriNopdfops:// uri of the inline application/pdf resource, when output_path was omitted

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.3.2
    • changedInput schema / properties / output_path / description
      Previous value: -"Absolute path to write the invoice PDF"New value: +"Absolute path to write the result. Omit when running remotely: the PDF is then returned inline as an application/pdf resource for the client to save."
    • changedInput schema / required
      Previous value: -[
-  "invoice",
-  "output_path"
-]New value: +[
+  "invoice"
+]
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "bytes": {
+      "description": "Size of the produced PDF in bytes",
+      "type": "integer"
+    },
+    "output_path": {
+      "description": "Absolute path written, when output_path was supplied",
+      "type": "string"
+    },
+    "resource_uri": {
+      "description": "pdfops:// uri of the inline application/pdf resource, when output_path was omitted",
+      "type": "string"
+    }
+  },
+  "required": [
+    "bytes"
+  ],
+  "type": "object"
+}
  2. First observedv0.2.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare idempotentHint=true and destructiveHint=false, and the description adds valuable behavioral context beyond those hints: it states the output is byte-identical for the same input, safe to re-run, overwrites existing files at output_path, and includes a footer without a paid key. These are meaningful operational details an agent needs to invoke and reason about the tool correctly.

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?

The description is information-dense but tightly structured, with the core purpose first, followed by determinism, licensing footer, output behavior, and sibling routing. Every sentence adds distinct value and none are redundant with the schema or annotations.

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?

Given the nested invoice schema, annotations, and output schema, the description covers all essential operational aspects: what the tool does, when to use it, what output to expect, side effects like overwriting, determinism guarantees, and licensing-related watermarking. No important invocation-relevant context 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 the baseline is 3. The description goes beyond the schema by explaining the output_path behavior: omitting it returns the PDF inline as an application/pdf resource, while providing it writes to that path and overwrites existing files. It also clarifies that the invoice parameter is structured data, reinforcing the 'no template needed' claim.

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 uses a specific verb ('generate') and resource ('invoice PDF'), and further clarifies it produces a complete professionally laid-out PDF from structured data with no template needed. It explicitly distinguishes itself from pdf_fill, which handles existing PDFs or fillable templates, making sibling differentiation clear.

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?

The description gives explicit when-to-use guidance: use when you have invoice DATA and no document. It also names the alternative (pdf_fill) and the condition for choosing it, i.e., if you already have an invoice PDF or a fillable template. This leaves no ambiguity about tool selection.

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

Deploy Server

Other Tools