Paperboy

Official

Overview Schema Source Related Servers Discussions Admin

run_pipeline

DestructiveIdempotent

Chain multiple PDF operations in one call, passing each step's output to the next and saving only the final processed PDF.

Instructions

Run several tools on a PDF in one call, each on the result of the one before, and save only the final result (default: "_processed.pdf"). Each step is {"tool": name, "args": {...}} with the same arguments as that tool, without input_path, output_path, password or overwrite, e.g. [{"tool": "decrypt_pdf"}, {"tool": "delete_pages", "args": {"pages": "1"}}, {"tool": "optimize_pdf"}, {"tool": "encrypt_pdf", "args": {"user_password": "x"}}]. Steps can be the tools that take one PDF and write one PDF: rotate_pages, delete_pages, extract_pages, rearrange_pages, decrypt_pdf, encrypt_pdf (last step only), optimize_pdf, repair_pdf, flatten_pdf, set_metadata, sanitize_pdf, add_watermark, add_page_numbers, fill_form, crop_pages, resize_pages, n_up, insert_blank_pages, set_outline, redact_pdf, ocr_pdf, add_comments, convert_to_pdfa (last step only); up to 20. password opens the input and is used by every step (decrypt_pdf removes it). Every step's arguments are checked before any step runs, and each step applies its tool's own rules. Steps hand files to each other in a private temporary folder, deleted afterwards; if a step fails, nothing is saved.

Any password argument can be "ask": the user then types it on a local page, so it never passes through the chat.

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": {
      "input_path": "<input_path>",
      "steps": "<steps>"
    },
    "name": "run_pipeline"
  }
}

Input Schema

Name	Required	Description	Default
`steps`	Yes
`password`	No
`overwrite`	No
`input_path`	Yes
`output_path`	No

Output Schema

Name	Required	Description	Default
`steps`	Yes
`output`	Yes
`password_protected`	Yes
`user_password_changed`	Yes
`permissions_restricted`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.1Nov 12, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Adds substantial context beyond the destructiveHint/readOnlyHint annotations: intermediates live in a private temp folder that is deleted, a failed step means nothing is saved, all step arguments are validated before any step executes, and the shared password propagates to every step. The 'ask' sentinel for passwords (typed on a local page, never passing through chat) is a genuine behavioral detail no schema could convey.

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-loads the core purpose, then the step format with a worked example, then constraints, then failure/temp-file semantics. Dense but well ordered; the long enumeration of admissible step tools is justified because it is a hard constraint, though it makes the paragraph heavy.

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?

For a 5-parameter tool with nested step objects and an output schema, the description covers validation timing, failure atomicity, temp-file cleanup, step ordering limits, and password propagation — everything an agent needs to compose a call correctly. The only omission is overwrite semantics, which matters given destructiveHint=true.

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 0%, so the description must carry the load, and it does for the hardest parameter: the steps array format is spelled out with a full example, the forbidden args (input_path, output_path, password, overwrite) are named, and password's dual role and 'ask' value are explained. output_path is only covered implicitly via the default filename, and overwrite is never described, leaving a small gap.

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 ('run several tools on a PDF in one call'), plus the chaining semantics (each step on the previous result) and the output behavior (only the final result is saved). This clearly distinguishes it from the single-purpose siblings like rotate_pages or optimize_pdf.

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 a concrete eligibility list of which tools may be steps, a cap of 20, and a positional constraint (encrypt_pdf and convert_to_pdfa only as the last step). It does not explicitly say when a caller should prefer this over calling the individual tools in sequence, but the 'one call, only final result' framing makes the tradeoff inferable.

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