pdfnative-mcp

Prepare signature placeholder

prepare_signature_placeholder

Idempotent

Generate a PDF with an embedded signature AcroForm placeholder for later digital signing. Use when you need to customize the placeholder size, attach to a specific page, or precompute the placeholder PDF separately.

Instructions

Create a PDF with an embedded /Sig AcroForm placeholder ready to be digitally signed by the sign_pdf tool. NOTE: as of v1.0.0, sign_pdf auto-injects a placeholder when missing (autoInjectPlaceholder defaults to true), so this tool is OPTIONAL. Use it only when you need to: (a) customize the placeholder size for >4096-bit RSA keys via placeholderBytes, (b) attach the signature widget to a specific page via pageIndex, or (c) precompute and ship the placeholder PDF separately from the signing step. Otherwise call sign_pdf directly with any PDF.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`title`	Yes	Document title. Used as the PDF metadata title and rendered at the top of page 1.
`signerName`	No	Name of the intended signer, embedded in the /Sig dictionary.
`reason`	No	Reason for signing (e.g. "Approved", "I agree to the terms").
`location`	No	Signing location (city / country).
`contactInfo`	No	Contact information for the signer.
`fieldName`	No	Optional AcroForm field name for the signature widget (default 'Signature1').
`placeholderBytes`	No	Reserved bytes for the future CMS /Contents blob (default 16384). Increase only for >4096-bit RSA or PAdES-B-LT.
`pageIndex`	No	Zero-based page index the (invisible) widget attaches to (default 0).
`pdfA`	No	Optional PDF/A conformance level (powered by pdfnative v1.2). Use 'pdfa1b' for archival of simple text+images, 'pdfa2b'/'pdfa2u' for richer content (2u guarantees Unicode mapping), 'pdfa3b' when embedding source attachments (Factur-X / ZUGFeRD). Mutually exclusive with PDF encryption. See docs/guides/PDFA.md. Note: PDF/A + signatures requires PAdES-A; verify with inspect_pdf.
`blocks`	No	Optional document body blocks rendered before the signature field.
`outputMode`	No	Either 'base64' (returns the PDF inline) or 'file' (writes to a sandboxed path inside PDFNATIVE_MCP_OUTPUT_DIR).	base64
`outputPath`	No	Required when outputMode='file'. Relative path inside the sandbox; must end with .pdf.

Output Schema

TableJSON Schema

Name	Required	Description
`mode`	Yes
`sizeBytes`	Yes
`filePath`	No	Absolute sandboxed file path (when mode='file').
`base64`	No	Base64-encoded PDF bytes (when mode='base64').

Tool Definition Quality

A4.7/5.0

Behavior4/5

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

Annotations already indicate idempotent=true and non-destructive. Description adds contextual behavior (optional, creates placeholder) without contradicting annotations, but could further detail side effects or state changes.

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?

Description is concise (4 sentences) with key info front-loaded, followed by a clear list of optional use cases. No extraneous content.

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?

For a tool with 12 parameters, full schema coverage, and an output schema, the description sufficiently explains the use case, workflow context, and when to use it versus sign_pdf, making it complete.

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 provides 100% parameter descriptions. Description adds value by linking use cases to specific parameters (placeholderBytes, pageIndex), though does not elaborate on all parameters beyond the schema.

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?

Description clearly states the tool creates a PDF with an embedded /Sig AcroForm placeholder for digital signing, and explicitly distinguishes it from the sibling sign_pdf tool by noting it's optional and listing specific customization scenarios.

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?

Description provides explicit when-to-use conditions (a, b, c) and directs users to use sign_pdf directly otherwise, offering clear guidance on tool selection.

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

Install Server

Other Tools

Latest Blog Posts

Lightport: Open-Sourcing Glama's AI Gateway
By punkpeye on April 27, 2026.
open source
OpenAI
Tool Definition Quality Score (TDQS)
By punkpeye on April 3, 2026.
mcp
The Hackers Who Tracked My Sleep Cycle
By punkpeye on March 26, 2026.
security

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Nizoka/pdfnative-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server