Razi Document Tools

Shrink a PDF's byte size while keeping it a PDF, for email limits or slow connections. Returns the compressed PDF; over MCP it is never inlined, arriving as a stored URL that stays retrievable for about 24 hours. Ghostscript on razi.pro's worker downsamples embedded images at a fixed 'ebook' preset — lossy, with no quality knob. Compression is not guaranteed: if the worker is unavailable the fallback only rewrites the file with object streams, which typically saves almost nothing, and when nothing can be saved the original bytes are returned unchanged. PDFs only: an image or a video is rejected, and neither can be re-encoded anywhere on this server. Paid compute; 20 calls per hour per IP; a large file can take minutes. There is no upload channel over MCP: pass `fileUrl`, a URL in razi.pro's own storage; third-party URLs are rejected. Obtain one by uploading the PDF over the REST API first (POST /api/v1/tools/execute with the file attached).

Use this ONLY when the text exists as PIXELS and nothing else — a photo, a screenshot, a scan. It runs optical character recognition on an image and GUESSES the characters, so it is a best-effort transcription that misreads under blur, skew or low contrast. Returns JSON { text, language, confidence? }. If the file already stores real characters, this is the wrong tool and will be less accurate: parse_document reads them exactly. The deciding question is what the bytes contain, never the file extension — a .png of a letter needs this tool, a .txt never does. Layout is not preserved — no tables, columns or coordinates, just a flat string. Paid compute; 20 calls per hour per IP. There is no upload channel over MCP: pass `fileUrl`, a URL in razi.pro's own storage; third-party URLs are rejected. Obtain one by uploading the image over the REST API first (POST /api/v1/tools/execute with the file attached).

Assemble pictures into one PDF, a page per picture, in the order supplied. PNG and JPEG bytes are embedded untouched; WebP, GIF, TIFF and AVIF are re-encoded to PNG on the way in, which loses no detail but does rewrite the file. A PDF sitting among the pictures is spliced in whole at its position, so a photo/contract/photo sequence takes one call. Each page defaults to the pixel dimensions of its picture, so nothing is scaled, cropped or letterboxed; choose 'a4' or 'letter' instead to centre every picture on a fixed portrait sheet, optionally inside a `margin` of blank points. Ceilings per call: 100 files, and 50MB summed across all of them, at 20 calls an hour per IP. Bytes that cannot be decoded as a picture — a spreadsheet, a video, a corrupt upload — earn an HTTP 400 naming the offending file; a blank page is never substituted to hide one. Output is the finished PDF: raw bytes over REST, and over MCP a link to the stored document that keeps working for roughly a day. MCP carries no attachments, so name the pictures with `fileUrls` — an ordered array of links inside razi.pro's own storage. Links elsewhere on the internet are refused. Mint them by POSTing the pictures to /api/v1/tools/execute first, where they may simply be attached.

Concatenate two or more PDFs into a single PDF, in the order supplied, and return the merged file. Over MCP the PDF is never inlined: it comes back as a stored URL that stays retrievable for about 24 hours. Page content is copied unchanged — it does not compress (use compress_pdf) or select pages (use split_pdf). Fewer than two files is rejected. Every input must already be a PDF; a photo handed to this tool is rejected rather than converted. Use images_to_pdf when any input is a picture — it takes PDFs alongside them and splices both in one pass. There is no upload channel over MCP: pass `fileUrls`, an array of URLs in razi.pro's own storage; third-party URLs are rejected. Obtain such a URL by uploading the file over the REST API first (POST /api/v1/tools/execute with the file attached). Over the REST API the files may instead be attached as multipart/form-data. Limited to 20 merges per hour per IP.

Use this when the file ALREADY stores its text as characters: it decodes them and returns JSON { text, metadata } verbatim, with no guessing involved. That exactness is the whole difference from extract_text_ocr, which recovers text from pixels by guessing at glyph shapes and should only ever be pointed at a photo, screenshot or scan. Supported: .txt, decoded as UTF-8 and returned in full with metadata { format: "txt", words }; and .pdf, where the text layer is read page by page and joined with a `--- Page N ---` separator, returning metadata { format: "pdf", pages, words } — pages and words are counted from the document itself, never estimated. .docx and every other extension are rejected with 400. A scanned or photographed PDF has no text layer, so nothing can be extracted from it here; that case returns 422 with a metadata.imageOnly flag rather than an empty success, and extract_text_ocr is the tool for it. Limits: 50MB and 300 pages, over which the call returns 413; an unreadable or encrypted PDF returns 400. Layout is not preserved — no tables, columns or coordinates, just a flat string per page. The file type is decided by the filename extension, not by inspecting the bytes. 10 calls per minute per caller. There is no upload channel over MCP: pass `fileUrl`, a URL in razi.pro's own storage; third-party URLs are rejected. Obtain one by uploading the file over the REST API first (POST /api/v1/tools/execute with the file attached).

Extract page ranges from one PDF into new PDFs. One output file is produced per range: a single range returns that PDF directly, several ranges return a ZIP containing one PDF each. Over MCP you receive a link to the stored output rather than its bytes, and that link keeps working for roughly a day. Pages are copied verbatim — this does not reduce file size (use compress_pdf) and it cannot rasterise pages into images, which is a browser-only feature of razi.pro. Every output stays a PDF. There is no upload channel over MCP: pass `fileUrl`, a URL in razi.pro's own storage; third-party URLs are rejected. Obtain one by uploading the PDF over the REST API first, where it may instead be attached as multipart/form-data. Limited to 20 splits per hour per IP.