Skip to main content
Glama

JustFill PDF Form Automation

Fill the PDF

fill_pdf
Destructive

Fill the PDF and return a download link (valid until the workspace expires).

`values` maps field id -> text (checkboxes: "yes"/"x"/"true" to tick).
`flatten=False` preserves existing form fields; it does not create fields
on scans. `fillable=True` creates interactive fields (subject to the
account's existing export entitlement) and takes precedence over flatten.
`editable`, `editable_widget_count` and `output_type` describe the actual PDF.
`editable` means at least one form widget is writable, not that all values are.
`warnings` lists text printed too small or cut off (with flatten=True
render_filled_preview reports them beforehand; with flatten=False editable
widgets are not measured). `output_mode` "watermarked" means the result
contains a JustFill watermark: deliver `download_url` clearly labeled as a
free watermarked preview AND always share `unlock_page_url`, `checkout_url`,
or `pro_checkout_url` with the user so they can download a clean,
unwatermarked PDF (or unlock Pro $49/mo for multi-page, API, and template
automation). A clean final output may consume one of the account's existing
fill entitlements; when none is available, the result is watermarked.

Visual review gate & workflow routing:
- For ML-detected layouts (`source="ml"`), `fill_pdf` requires prior
  `render_preview` and `render_filled_preview` calls (with matching `values`,
  `flatten`, and `fillable` flags) on every populated page; otherwise it
  returns `required_calls` without generating the PDF.
- Use `render_filled_preview` first to verify placement and text fit at no
  cost; call `fill_pdf` only when ready to generate the downloadable PDF.
- Do not call `close_workspace` until the user has downloaded the file from
  `download_url`.

Input Schema

NameRequiredDescriptionDefault
valuesYesNon-empty mapping of `field_id` (from `open_pdf` or `list_fields`) to the string value to fill. Checkboxes tick on `'yes'`, `'x'`, or `'true'`. Must not contain restricted data (payment cards, PHI, government IDs, or authentication secrets).
flattenNoIf `True` (default), flattens filled values into static page content. If `False`, preserves existing embedded AcroForm widgets as editable fields.
fillableNoIf `True`, synthesizes interactive, editable AcroForm widgets for the fields in the output PDF (subject to account entitlement; takes precedence over `flatten`).
workspace_idYesActive workspace ID returned by `open_pdf` (`summary.workspace_id`).

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / properties / fillable / description
      Added value: +"If `True`, synthesizes interactive, editable AcroForm widgets for the fields in the output PDF (subject to account entitlement; takes precedence over `flatten`)."
    • addedInput schema / properties / flatten / description
      Added value: +"If `True` (default), flattens filled values into static page content. If `False`, preserves existing embedded AcroForm widgets as editable fields."
    • addedInput schema / properties / values / description
      Added value: +"Non-empty mapping of `field_id` (from `open_pdf` or `list_fields`) to the string value to fill. Checkboxes tick on `'yes'`, `'x'`, or `'true'`. Must not contain restricted data (payment cards, PHI, government IDs, or authentication secrets)."
    • addedInput schema / properties / workspace_id / description
      Added value: +"Active workspace ID returned by `open_pdf` (`summary.workspace_id`)."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare destructive/ non-idempotent, and the description adds substantial context beyond them: entitlement consumption, watermarking behavior and required user-facing URLs, the required_calls failure mode, and what warnings measure under each flatten mode. No contradiction with the mutation-oriented annotations.

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?

Front-loaded purpose followed by parameter notes and a clearly delimited workflow section; dense but nearly every clause carries operative information. Slight redundancy in explaining output fields (editable, editable_widget_count, output_type, warnings) that an existing output schema already enumerates, though the 'editable means at least one widget writable' nuance earns its place.

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 destructive, entitlement-gated generation tool with nested values and a mandatory preview gate, the description covers gating, cost implications, watermark handling, and cleanup ordering. With an output schema present, it correctly stops short of documenting return structure in detail.

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 coverage is 100%, so the baseline is 3, but the description adds real meaning: flatten=False 'does not create fields on scans' (a behavioral limit absent from the schema), and fillable 'takes precedence over flatten'. Checkbox value semantics are repeated from the schema, limiting it to a 4.

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?

Opens with a specific verb+resource and states the concrete result: 'Fill the PDF and return a download link (valid until the workspace expires).' It also implicitly separates itself from the preview sibling by saying 'call fill_pdf only when ready to generate the downloadable PDF,' so an agent can pick it apart from render_filled_preview without opening schemas.

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?

Explicit section 'Visual review gate & workflow routing' states ordering rules (render_filled_preview first), a hard precondition for ml layouts including the exact fields that must match, and a downstream constraint ('Do not call close_workspace until the user has downloaded'). Alternatives and when-not conditions are named rather than implied.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.