Skip to main content
Glama
s3eidat

S3eidat Tools MCP

by s3eidat
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Watermark PDF

pdf_watermark
Read-onlyIdempotent

Add centered or tiled text or image watermarks to selected PDF pages with opacity, angle, size, color, and page-range controls, including image fallback for unsupported text.

Instructions

Stamp a text or image watermark on PDF pages: centred or tiled across the page, with opacity, angle, size, colour and a page range. It reads upright on rotated pages. Text the standard PDF fonts cannot draw (Arabic, CJK…) is stamped as an image. Defaults match the website: "CONFIDENTIAL", Helvetica Bold 72 pt, #d64545, 25% opacity, 45°. Web version: https://s3eidat.github.io/pdf-watermark/

Input Schema

NameRequiredDescriptionDefault
gapNoSpace between tiles in points (tile mode). Default 80.
fileYesThe PDF: a local file path (absolute, or relative to the server's --root) or base64 data (raw or a data: URI).
fontNoFont for text.HelveticaBold
modeNo"center": one stamp in the middle; "tile": repeated across the page.center
sizeNoText size in points. Default 72.
textNoWatermark text (default "CONFIDENTIAL"). Ignored when "image" is given.
angleNoRotation in degrees, counter-clockwise as shown. Default 45.
colorNoColour as hex "#rrggbb". Default #d64545.#d64545
imageNoImage watermark instead of text: a local path or base64 (PNG, JPEG, WebP, SVG…).
pagesNoPages to stamp: 1-based list like "1-3, 5, 8-" ("5-" = to the end, "-3" = first three, "3-1" = reversed). Also "all", "odd", "even", "last". Empty = all pages.
scaleNoImage width as % of the page width. Default 40.
outputNoWhere to write the result: a file path, or a folder ending in "/". Default: the server output folder (a temp folder unless --out-dir is set).
opacityNoOpacity in % (1-100). Default 25.
returnBase64NoAlso return the output as base64 in the result (only for small files). Default false.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Beyond the annotations, the description discloses real behavior: orientation handling on rotated pages, the fallback that stamps non-Latin text as an image, and that results are written to an output destination rather than mutating the source. It does not state whether the input PDF is left untouched or what the response contains, which keeps it off a 5.

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?

Four tight sentences, front-loaded with the core action and followed by behavior and defaults; nothing is padded. The trailing web-version URL is mildly off-task but negligible.

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 14-parameter tool with no output schema, the description covers the main behavioral surprises (rotation, font fallback, output destination) and the default look. It stops short of explaining the response shape or the base64 return path, which the schema only hints at.

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

Parameters3/5

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

Schema description coverage is 100%, so every one of the 14 parameters is already documented, including the page-range grammar and enum values. The description mostly repeats the defaults the schema already carries; its only added semantic is the font-fallback rule for unsupported scripts (which is parameter-adjacent but not tied to a specific field).

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?

"Stamp a text or image watermark on PDF pages" gives a specific verb and resource, and the following clause enumerates the modes (centred/tiled) and styling knobs. It is clearly distinguishable from siblings like image_watermark and pdf_sign_image because it is scoped to PDF pages and text/image stamps.

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

Usage Guidelines3/5

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

Usage context is implied by the feature list (text vs image mode, page range, rotated pages) but there is no explicit when-to-use statement and no named alternative (e.g. image_watermark or pdf_page_numbers) to route against. An agent can infer the right context but must reason it out from the schema.

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