pdf-form-proof
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| pdf_form_inspectA | List every fillable field in a PDF: exact name, type (text, button, choice, signature), current value, required flag, and for checkboxes/radios the on-state values that check them. Use the names exactly as returned when filling. |
| pdf_form_fillA | Fill an AcroForm PDF and write a NEW file (the source is never modified and an existing output is never overwritten). values maps exact field names to values: strings for text fields; an on-state such as "/1" or "/Yes" (or true) to check a box, "" or false to clear it. strict=true refuses the whole fill if any name is unknown. finalize=true removes the XFA packet and NeedAppearances flag so viewers render the values from their own appearance streams (fields stay editable; this is not flattening). Returns the output SHA-256 and a read-back of every text value. |
| pdf_form_verifyA | Render one page, OCR it, and compare with the PDF text layer. Each value gets a verdict: VISIBLE, INVISIBLE (in the file but not on the page), RENDER-ONLY, or MISSING. region is "page" or "x0,y0,x1,y1" as page fractions; with a region and auto=true every word the text layer places in that region must also be legible. A tool failure (missing poppler or tesseract, render error) returns REFUSE with the reason and makes no finding about the document. Proves legibility only, not correctness. |
| pdf_sha256B | Return the SHA-256 digest of a file so the exact output can be recorded. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool targets a distinct verb on the PDF: inspect (read fields), fill (write new file), verify (render+OCR compare), and hash (record output). Boundaries are crisp, with no overlap, and the descriptions explicitly note scope limits (verify proves legibility, not correctness).
Consistent snake_case and a shared pdf_ prefix throughout. Minor deviation: pdf_sha256 breaks the pdf_form_* pattern and is a generic utility rather than a form operation, but it remains predictable and readable.
Four tools is lean but each earns its place in a tight fill-and-proof workflow with no redundancy. Slightly on the thin side for the implied scope, but well-scoped rather than padded.
Covers the full loop: enumerate fields, fill safely to a new file, verify rendering, and record the output digest. Minor gaps like batch/multi-file handling or field validation reporting are absent but workable given the narrow purpose.