Skip to main content
Glama
Nizoka

pdfnative-mcp

Sign PDF (RSA / ECDSA, PAdES)

sign_pdf

Sign any PDF with a PAdES-compatible digital signature using RSA or ECDSA in one API call.

Instructions

Apply a PAdES-compatible CMS digital signature to a PDF. Since v1.0.0 you can sign ANY PDF in ONE call — autoInjectPlaceholder defaults to true, so you do NOT need to run prepare_signature_placeholder first unless you want to customize the placeholder appearance. Supports RSA-SHA256 and ECDSA-SHA256 (P-256). Required inputs: pdfBase64, algorithm, certDerBase64, plus EITHER rsaKeyPkcs1DerBase64 (when algorithm='rsa-sha256') OR ecPrivateScalarHex / ecPrivateKeyDerBase64 (when algorithm='ecdsa-sha256'). To convert PEM keys to DER base64: openssl pkey -in key.pem -outform DER | base64 -w0. To convert a PEM X.509 cert: openssl x509 -in cert.pem -outform DER | base64 -w0. After signing, call verify_pdf to confirm validity.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
reasonNo
locationNo
algorithmYesSignature algorithm. ECDSA only supports P-256 in v1.0.0.
pdfBase64YesBase64-encoded PDF bytes. When the PDF already contains a /Sig placeholder it is signed in place; otherwise the placeholder is auto-injected (set autoInjectPlaceholder=false to opt out).
outputModeNobase64
outputPathNo
signerNameNo
contactInfoNo
signingTimeNoISO-8601 timestamp. Defaults to now.
certDerBase64YesBase64 of the signer X.509 certificate in DER form. Convert from PEM with: openssl x509 -in cert.pem -outform DER | base64 -w0
ecPrivateScalarHexNoHex-encoded P-256 private scalar `d` (exactly 64 lowercase or uppercase hex chars, no 0x prefix). Mutually exclusive with ecPrivateKeyDerBase64; either is accepted for ECDSA.
rsaKeyPkcs1DerBase64NoBase64 of the RSA private key in PKCS#1 RSAPrivateKey DER (NOT PKCS#8, NOT PEM). Required when algorithm=rsa-sha256. Convert from PEM with: openssl rsa -in key.pem -outform DER -traditional | base64 -w0 (the -traditional flag forces PKCS#1).
autoInjectPlaceholderNoWhen true (default) and the input PDF has no /Sig widget, pdfnative.addSignaturePlaceholder is called before signing — enabling single-call signing of any PDF.
ecPrivateKeyDerBase64NoBase64 of an ECDSA P-256 private key in SEC1 (RFC 5915) or PKCS#8 (RFC 5208) DER form. Convert from PEM with: openssl pkey -in key.pem -outform DER | base64 -w0 Mutually exclusive with ecPrivateScalarHex.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeYes
filePathNoAbsolute sandboxed file path (when mode='file').
sizeBytesYes
Behavior3/5

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

While annotations are sparse, the description explains the auto-injection behavior, algorithm support, and key requirements. However, it does not disclose potential side effects like overwriting the input PDF or size limitations. The mutation nature is implied but not explicitly stated.

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?

The description is well-structured with a clear first sentence followed by logical details. Though slightly lengthy, every sentence serves a purpose. Minor redundancy with schema descriptions could be trimmed.

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?

Given the tool's complexity (14 parameters, 3 required), the description covers purpose, usage, algorithm details, and post-signing verification. Edge cases like error handling are missing, but the output schema likely covers return values.

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?

With 57% schema description coverage, the description adds significant value by explaining the mutual exclusivity of ECDSA key parameters, providing conversion commands, and clarifying the autoInjectPlaceholder default. This goes beyond the schema entries.

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?

The description clearly states the tool applies a PAdES-compatible CMS digital signature to a PDF. It distinguishes from sibling tools like prepare_signature_placeholder by noting that auto-injection makes a separate placeholder step unnecessary.

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?

Explicitly tells when to use the tool (single call for any PDF due to autoInjectPlaceholder) and when to use the alternative prepare_signature_placeholder (for customizing placeholder appearance). Also recommends calling verify_pdf after signing.

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

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