watermark_pdf
Stamp a diagonal text watermark across every page of a PDF. Returns a downloadable URL.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Base64-encoded PDF. | ||
| text | No | Watermark text (default "DRAFT"). |
Stamp a diagonal text watermark across every page of a PDF. Returns a downloadable URL.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Base64-encoded PDF. | ||
| text | No | Watermark text (default "DRAFT"). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It states that the watermark is applied to every page, the watermark is diagonal text, and it returns a downloadable URL, which implies a non-destructive operation producing a new file. While it does not cover error cases or side effects, the disclosed behavior is adequate for this simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the action and the output. There is no redundant or filler content; every word adds value, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with only two parameters and no output schema. The description sufficiently explains the core behavior and explicitly states the return type ('downloadable URL'), which covers the essential context needed for a user to understand and invoke the tool. It does not elaborate on edge cases or error conditions, but these are not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameters with individual descriptions, providing clear semantics for 'pdf' and 'text'. The tool description adds no additional parameter-level meaning, so the baseline score of 3 applies here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Stamp a diagonal text watermark across every page of a PDF.' The verb 'stamp' and the resource 'PDF' identify the action and target, while the qualifiers 'diagonal text watermark' and 'every page' add specificity. It also mentions the return type, distinguishing it from sibling tools like merge_pdfs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly discuss when to use this tool versus alternatives, nor does it name any exclusions. However, the purpose is self-evident from the name and description, so usage is implied rather than explicitly guided. A clear statement about when to choose this over merge_pdfs or generate_pdf would improve this dimension.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
All six tools have clearly distinct purposes: converting markdown to different formats, merging/stamping PDFs, and checking recalls. No two tools are easily confused.
Most tools use a verb_noun pattern (generate_pdf, merge_pdfs, watermark_pdf, check_recalls), but markdown_to_docx and markdown_to_html use a different pattern (source_to_target). The inconsistency is minor and still readable.
With 6 tools, the count is reasonable for a document conversion utility. However, the inclusion of check_recalls feels out of place for a server named 'pdf', slightly diluting focus.
The tool set covers markdown-to-PDF and PDF merging/watermarking, but lacks PDF-to-other-format conversion, splitting, or editing. The recall checker is an unrelated gap filler. Core PDF workflows are partially covered.