What can you do with this server?

The JustFill PDF Forms server lets AI agents detect, review, fill, and manage fields in PDF forms (including scanned images) programmatically. * Open & detect PDF fields: Open a PDF or scanned image (JPG/PNG/TIFF) and automatically detect fillable fields using saved templates, embedded AcroForm fields, or ML detection — with confidence scores for each field. * Preview fields: Render page images with color-coded field box overlays to visually verify placement (blue = deterministic, green/orange/red = ML confidence levels). * Preview filled output: See how the filled PDF will look with your values drawn in place — without consuming a fill credit or generating the actual PDF. * List fields: List all detected fields, optionally filtered to a specific page. * Add/Update/Remove fields: Manually correct detection errors (false negatives/positives) by adding, updating, or removing fields individually or in batch, including position, size, name, type, and text alignment. * Prune fields: Bulk-delete detection noise using combined criteria (field type, confidence threshold, size thresholds, page, or exclusions). * Fill PDF: Populate the PDF with provided values (field ID → text) and save the output file, with warnings for values that will be shrunk or truncated. * Save templates: Persist a reviewed field layout as a named, reusable template for fully deterministic future fills (confidence 1.0, no ML needed). * List templates: View all saved templates, including name, field count, and file hash.

Which integrations are available for this server?

Enables n8n workflows to detect, review, and fill PDF form fields through justfill.app, allowing automated PDF form processing with ML detection and template reuse.

JustFill PDF Forms

by mrmaciej1

Overview Schema Related Servers Score Discussions

Python

Local

JustFill MCP Server

Let AI agents (Claude, ChatGPT, n8n — any MCP client) detect, review and fill PDF form fields through justfill.app.

Excel or CSV batch workflow

If the source data is already in a spreadsheet and you need one filled copy of the same existing PDF per row, an MCP client is optional. The guided browser workflow imports XLSX or CSV, maps columns to reviewed PDF fields, previews each record, and exports the approved PDFs in a ZIP.

Try the five-row PDF mail merge sample — no card or sales call.

Related MCP server: pdf-filler-mcp

Import-ready n8n workflows

Start with the free reviewed template in the official n8n workflow catalog. It collects a PDF and JSON payload, reuses the reviewed field names saved for that exact form, fills the original layout and returns a temporary download link.

The repository also includes the exact deterministic workflow JSON, synthetic test PDF, production evidence and a separate two-pass vision workflow for an unfamiliar form. Both call the hosted MCP endpoint with standard HTTP Request nodes and can be inspected before adding credentials.

Inspect the source workflows and evidence, or follow the step-by-step n8n setup.

Business example: recurring supplier intake

An operations team can keep the supplier's required intake PDF unchanged, save its reviewed field layout once, and let n8n map approved vendor data from a webhook or CRM record into that exact form. The workflow returns a temporary filled-PDF link that can be reviewed before it is uploaded to Drive, attached to a draft email, or written back to the vendor record. The repository's synthetic supplier-intake PDF exercises this exact path without customer data.

Gemini CLI extension

Install the same reviewed MCP tools plus the included PDF workflow guidance:

gemini extensions install https://github.com/mrmaciej1/justfill-mcp

The extension manifest lives at the repository root and uses the published justfill-mcp package. Gemini CLI asks for normal third-party extension consent before enabling it.

Why agents can trust it

Source	Confidence	What it means
Saved template	1.0	This exact PDF was filled before; geometry is human/agent-verified. No ML runs at all.
AcroForm	1.0	The PDF has embedded form fields — read from the file, filled natively.
ML detection	0.0–0.95	An honest draft. Review it visually (`render_preview`), fix it, then `save_template` to lock it in.

ML confidence is calibrated: the detector's raw scores are not probabilities (its server-side filter accepts boxes from raw ~0.02 and auto-accepts at raw 0.15), so they are mapped onto 0–1 to mean what you'd expect — ≥0.75 "detector is sure", 0.4–0.75 "probably right, glance at the preview", <0.4 "borderline accept, verify". The raw detector score is kept on each field as raw_score.

The correction loop (render_preview → add/update/remove_field) exists precisely because ML detection has false positives and negatives. A false positive costs nothing (leave it unfilled or remove it); a false negative is visible on the preview and fixable with one add_field call. Once reviewed, save_template makes every future fill of that form deterministic.

Setup

uv tool install justfill-mcp

Authorize once (opens the browser, one click while logged in to justfill.app):

justfill-mcp login

Then the config needs no credentials at all:

{
  "mcpServers": {
    "justfill": { "command": "justfill-mcp" }
  }
}

For a zero-install configuration, use uvx directly:

{
  "mcpServers": {
    "justfill": {
      "command": "uvx",
      "args": ["justfill-mcp"]
    }
  }
}

Alternatives, in the order the server checks them:

JUSTFILL_API_KEY env — create a key at justfill.app → Account → API Keys and put "env": {"JUSTFILL_API_KEY": "jf_live_…"} in the config.
The key saved by justfill-mcp login (~/.config/justfill/credentials.json).
JUSTFILL_EMAIL + JUSTFILL_PASSWORD — legacy fallback; an API key is better (no password in config files, revocable per client, never expires mid-session).

Tools

open_pdf(path, min_confidence=0.0, max_pages=10, force_detect=False) — template → AcroForm → ML resolution order. Accepts scanned images too (jpg/png/tiff → converted to PDF, deterministically, so templates still match). force_detect=True ignores a saved template and re-runs ML.
render_preview(page_index) — page image with labeled field boxes (blue = deterministic, green/orange/red = ML confidence)
render_filled_preview(values, page_index) — the same page with your values drawn in place (checkboxes get an X). Costs no fills — check before you fill.
list_fields(page_index?)
add_field(x, y, w, h, name, page_index, field_type, align?, vertical_align?) — coords in % of page, top-left origin
update_field(field_id, …) / remove_field(field_id)
update_fields([{field_id, …}, …]) / remove_fields([ids]) — batch versions
prune_fields(field_type?, confidence_below?, width_below?, height_below?, page_index?, exclude_ids?) — bulk-delete detection noise in one call (criteria AND-ed, removed ids returned)
fill_pdf(values, output_path, flatten=True) — values = {field_id: text}; responds with warnings for values that will be shrunk/truncated to fit
save_template(name) — persist the reviewed layout for deterministic repeat fills
list_templates()

Text alignment: align = left|center|right, vertical_align = top|middle|bottom — set per field (e.g. right for RTL forms, center for boxed digits). Persisted in templates.

Example agent flow

open_pdf("~/forms/w-9.pdf")            → acroform, 27 fields, confidence 1.0
fill_pdf({"f1": "Jane Doe", …}, "~/out/w-9-filled.pdf")

open_pdf("~/forms/scan.jpg")           → converted to PDF; ml, 34 fields
render_preview(0)                      → agent sees noise + one missed line
prune_fields(field_type="cell", width_below=3)   → 16 removed in one call
add_field(x=18, y=62.5, w=40, h=3, name="Phone")
render_filled_preview({…})             → values sit right, no overflow
fill_pdf({…}, "~/out/filled.pdf")
save_template("Client intake form")    → next time: deterministic

Notes

Auth is a regular justfill.app account; tokens auto-refresh on expiry.
Usage and document-output rules are enforced by the same account service as the web app. fill_pdf reports whether the output is clean or watermarked.
One PDF open at a time per server session (by design — keeps ids stable).
This repository mirrors released versions of the MCP client (development happens in a private monorepo alongside the justfill.app backend). Bug reports and feature requests are very welcome in the issue tracker here.

Available Tools

14 tools

add_fieldAInspect

Add a field the detector missed (a false negative).

Coordinates are percentages of the page (0-100), top-left origin — read them off the render_preview image proportionally. align ('left'|'center'|'right') and vertical_align ('top'|'middle'|'bottom') control where the value sits inside the box when the PDF is filled.

ParametersJSON Schema

Name	Required	Default
`h`	Yes
`w`	Yes
`x`	Yes
`y`	Yes
`name`	No
`align`	No
`field_type`	No	text
`page_index`	No
`vertical_align`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description bears full burden. It explains the coordinate system (percentages, top-left origin), the meaning of align and vertical_align parameters, and how values are positioned. However, it omits behavioral details like what happens on duplicate names, field_type/drop behavior, or page_index scope.

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?

The description is efficient: four sentences that front-load the purpose, then add coordinate and alignment details. No redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 9 parameters, no schema descriptions, no annotations, and an existing output schema? the description covers the most critical input semantics but omits name, field_type, and page_index. It also does not reference the output schema. There are clear gaps for a tool with this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description must compensate. It explains x,y,w,h as percentages with top-left origin, and align/vertical_align with value constraints. But name, field_type, and page_index are not explained, leaving gaps for 4 of 9 parameters.

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 adds a field that the detector missed (false negative), which is a specific verb+resource. It distinguishes from siblings like update_field (modify existing) and remove_field (delete) by focusing on adding missed detections.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for adding missed fields based on detector output, but does not explicitly state when not to use it or mention alternatives among the sibling tools. The context is clear but guidance is implicit.

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

close_workspaceAInspect

Release the current PDF and field data when work is finished.

Saved templates and output PDFs are not deleted. This operation is idempotent, which makes it safe to call from automation cleanup blocks.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description effectively discloses key behaviors: saved templates and output PDFs are not deleted, and the operation is idempotent. It could add more, but covers essential traits for safe invocation.

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?

The description is two concise sentences with no wasted words. The first sentence states the purpose, the second adds important behavioral context, achieving excellent efficiency.

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 no parameters and an output schema exists (so return values not needed), the description adequately covers the tool's action and non-destructive nature. Minor missing detail is timing relative to other operations, but it's largely 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?

There are no parameters, so the description does not need to add meaning. Baseline 4 per rule for zero parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'Release' and the resource 'current PDF and field data', making the tool's main function obvious. However, it does not explicitly differentiate from sibling tools, though the cleanup purpose is distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises use 'when work is finished' and highlights idempotency for automation, providing clear usage guidance. It lacks explicit when-not-to-use advice but the context is sufficient.

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

fill_pdfAInspect

Fill the PDF and save it.

values maps field id -> text value (checkboxes: "true"/"yes"/"x" to tick). Fields not present in values stay empty. AcroForm fields are filled natively inside the PDF; everything else is drawn at its exact box. The response's warnings list flags values that will be shrunk or truncated to fit their box — fix those before delivering the document.

ParametersJSON Schema

Name	Required	Description	Default
`values`	Yes
`flatten`	No
`output_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior4/5

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

The description discloses key behaviors: how AcroForm fields are filled natively vs. drawn for others, and that warnings flag values that are shrunk/truncated. Since no annotations exist, the description carries full weight. However, it lacks details on failure modes or access requirements.

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?

The description is very concise: three sentences without any redundant text. The first sentence states the core purpose, followed by terse but necessary details. Every sentence adds value.

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 output schema exists (not shown), the description need not detail return values. It covers the main filling behavior and the warning list. Still, it omits edge cases like invalid field IDs or missing output paths, but these are minor for a tool of this complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The explanation of `values` (field id->text mapping, checkbox handling) adds meaning beyond the schema, and `output_path` is implied. However, `flatten` is not mentioned at all, and schema coverage is 0%, so the description does not fully compensate for the missing parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool fills a PDF and saves it, which is a specific verb+resource. While it does not explicitly distinguish from sibling tools like render_filled_preview, the 'save it' part differentiates it from pure rendering tools. Overall, the purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or which sibling tools are better suited for specific scenarios. The only usage hint is implicit from the description's focused task.

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

list_fieldsCInspect

List the current working fields (optionally one page only).

ParametersJSON Schema

Name	Required	Description	Default
`page_index`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations, the description carries full burden. It implies a read operation but does not explicitly state it is non-destructive, nor does it mention pagination behavior beyond a vague hint. No details on output structure or side effects.

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?

Single sentence with no extraneous words. Front-loaded with core purpose. Very concise while still conveying optional behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having an output schema (unknown content), the description lacks scope, explanation of 'current working fields', and any filtering capabilities. For a listing tool, more context is expected.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds some meaning to the page_index parameter by noting optional pagination, but it does not clarify that page_index specifies which page or what values are valid. Since schema has no description, this is a minor improvement.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action (list) and the resource (current working fields), and adds the optional page constraint. It distinguishes from sibling tools like add_field, remove_field, etc. However, 'current working fields' is somewhat vague.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool vs alternatives like prune_fields or render_preview. The description does not include context for using the optional page parameter or any prerequisites.

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

list_templatesCInspect

List saved templates on this account (name + field count + hash).

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as read-only nature, pagination, or rate limits. A simple 'List' implies read-only but is not explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short and front-loads the purpose, but it lacks structure and details. It is concise but not optimally informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the output schema exists, the description needn't explain return values, but it omits any mention of pagination or ordering. The description is somewhat incomplete for a listing tool with many siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain the 'limit' parameter or its behavior (e.g., max limit, pagination). The description adds minimal value 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?

The description clearly states the verb 'List' and the resource 'saved templates', and specifies the output fields (name, field count, hash). It distinguishes from sibling tools like list_fields, which lists fields, and other template-related tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives like list_fields or other template tools. With 13 siblings, explicit usage context is missing.

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

open_pdfAInspect

Open a PDF (or a scanned image: jpg/png/tiff) and detect its fillable fields.

Images are converted to a single-page PDF automatically (deterministically, so a template saved for a photo matches the same photo next time).

Resolution order (best source wins):

Saved template matching this exact file (deterministic, confidence 1.0)
Embedded AcroForm fields (deterministic, confidence 1.0)
ML detection (each field carries a confidence score)

force_detect=True skips steps 1-2 and re-runs ML detection from scratch — use it to rebuild a layout when the saved template is wrong or stale. min_confidence drops ML fields scored below it (templates/AcroForm are always kept). Returns a JSON summary + the field list.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes
`max_pages`	No
`force_detect`	No
`min_confidence`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.8/5.0

Behavior5/5

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

No annotations provided, so description fully discloses traits: image conversion deterministic, resolution order, skipping steps with force_detect, and confidence handling. No contradictions.

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?

Well-structured with bullet points, front-loads purpose, every sentence adds value. Appropriately sized for the complexity.

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?

Highly complete given 4 params, no annotations, and output schema present. Only max_pages is not explained, but overall thorough.

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 0%, but description adds meaning for path, force_detect, and min_confidence. Missing explanation of max_pages parameter, which is a minor gap.

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 it opens a PDF or scanned image and detects fillable fields, listing three resolution methods. It distinguishes itself from sibling tools like fill_pdf or list_fields.

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 explains when to use force_detect, min_confidence, and the resolution order. Provides clear context for when to use this tool vs alternatives.

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

prune_fieldsAInspect

Bulk-delete fields matching ALL given criteria (e.g. detection noise).

field_type: exact type match (e.g. 'cell'); confidence_below / width_below / height_below: strictly-less-than thresholds (w/h in % of page); page_index: limit to one page; exclude_ids: always keep these. Returns the removed ids so the operation is auditable (and reversible via add_field if it cut too much).

ParametersJSON Schema

Name	Required	Description	Default
`field_type`	No
`page_index`	No
`exclude_ids`	No
`width_below`	No
`height_below`	No
`confidence_below`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

The description discloses that removed IDs are returned for auditability and that the operation is reversible via add_field. It also explains that thresholds are strictly-less-than and that page_index limits to one page. However, it does not describe what happens when no criteria are provided (e.g., deletes nothing or everything), which is a behavioral gap.

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?

The description is concise (3 sentences), front-loaded with the purpose, and logically structured: purpose first, then parameter details, then return value and reversibility. Every sentence serves a clear purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite explaining parameters and return value, the description omits a critical detail: the behavior when no criteria are provided. Since all parameters are optional, an agent might invoke the tool with no arguments, potentially deleting all fields—a dangerous outcome. The description should clarify this edge case.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With schema description coverage at 0%, the description fully compensates by explaining each parameter's semantics: field_type for exact match, confidence_below/width_below/height_below as strictly-less-than thresholds (width/height in % of page), page_index to limit to one page, and exclude_ids to keep fields. This adds critical meaning beyond the bare 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?

The description clearly states the tool's purpose: 'Bulk-delete fields matching ALL given criteria.' It specifies a verb (delete) and resource (fields), and the phrase 'ALL given criteria' and example 'detection noise' distinguish it from siblings like remove_field (single) or remove_fields (possibly different criteria).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description lacks explicit guidance on when to use this tool versus alternatives. It does not warn about potential dangers (e.g., deleting all fields if no criteria are provided) or specify prerequisites. The sibling tools include remove_field and remove_fields, but no comparison is made.

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

remove_fieldCInspect

Delete a field that isn't a real input (a false positive).

ParametersJSON Schema

Name	Required	Description	Default
`field_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.4/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavior. It states deletion but does not mention side effects, prerequisites (e.g., field must exist, must be a false positive), or what happens after deletion.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (one sentence), but it omits necessary details. For a destructive single-parameter tool, it should be longer to provide behavioral and usage context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple but lacks completeness. Despite having an output schema, the description does not mention return value or confirm deletion. It also does not specify that the field_id must correspond to a false positive field.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, and the description does not add meaning to the single parameter 'field_id'. It mentions 'false positive' but does not explain how to identify such a field or what value to provide for field_id.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool deletes a field that is a false positive. It uses specific verb 'delete' and resource 'field'. However, it does not distinguish from sibling tools like 'remove_fields' which might delete multiple fields.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives like 'prune_fields' or 'remove_fields'. No exclusions or context are given.

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

remove_fieldsBInspect

Delete many fields in one call (batch version of remove_field).

ParametersJSON Schema

Name	Required	Description	Default
`field_ids`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided; description only says 'Delete' without mentioning behavioral traits like idempotency, error handling, or whether it's destructive. Minimal disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence, front-loaded with action. Adequate length for a simple tool but lacks necessary detail on parameters and behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Output schema exists but tool is a mutation with no annotations; description does not cover important aspects like permissions or limits, making it incomplete for safe invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%; description adds no meaning to the 'field_ids' parameter beyond its existence. No format, source, or validation hints.

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 states 'Delete many fields in one call' with specific verb and resource, and distinguishes from sibling 'remove_field' as batch version.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clear indication that this is a batch version of 'remove_field', implying use when multiple fields need deletion. No explicit exclusions or alternatives given, but sibling tools provide context.

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

render_filled_previewAInspect

Preview how the filled page will look BEFORE generating the PDF.

Draws values (field id -> text; checkboxes get an X) into their boxes on the rendered page. Costs nothing — no fill is consumed. Typography is an approximation of the final output (the server typesets the real PDF), so use it to verify placement, alignment and obvious overflow, then fill_pdf.

ParametersJSON Schema

Name	Required	Description	Default
`values`	Yes
`page_index`	No

TDQS

A4.7/5.0

Behavior4/5

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

Discloses typography approximation and no resource consumption, but does not detail behavior for invalid values or page_index beyond default.

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?

Four brief, well-structured sentences covering purpose, mechanics, cost, limitation, and usage advice; no redundancy.

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?

Provides complete guidance on when and how to use, what to expect, and next step, compensating for lack of annotations and output schema.

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?

Explains values as field-id-to-text mapping with checkbox support, but page_index is left without explanation despite 0% schema coverage.

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?

Clearly states it previews the filled page before PDF generation, explains it draws values into boxes, and distinguishes from fill_pdf.

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 advises to use for verifying placement, alignment, and overflow before calling fill_pdf, and notes no cost/fill consumption.

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

render_previewAInspect

Render a page with the working field boxes drawn on it.

Look at this image to VERIFY placement: blue boxes are deterministic (template/AcroForm/agent-placed); green/orange/red are ML detections by confidence (>=0.7 / >=0.4 / <0.4). Each box is labeled with its field id.

ParametersJSON Schema

Name	Required	Description	Default
`page_index`	No

TDQS

A3.9/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It transparently explains the color coding (blue=deterministic, green/orange/red=confidence levels) and that labels show field IDs. It does not address safety or rate limits, but for a preview tool, this behavioral disclosure is sufficient.

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?

The description is two concise sentences front-loaded with purpose, followed by necessary details about color coding. Every sentence adds value with no redundancy.

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?

For a preview tool with one parameter and no output schema, the description adequately explains the output (rendered page with boxes), color meanings, and verification purpose. Missing parameter documentation slightly reduces completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has one parameter (page_index) with 0% description coverage. The description does not mention page_index or provide any semantic guidance beyond the schema's default value. This is a significant gap as the parameter's meaning is left entirely to 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?

The description clearly states the tool renders a page with field boxes, with specific color coding distinguishing deterministic vs ML detections. This verb+resource specification is distinct from siblings like fill_pdf or render_filled_preview.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use for verification of placement via visual inspection, but does not explicitly state when to use or avoid this tool relative to alternatives such as render_filled_preview or list_fields. No exclusions or context for selection are provided.

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

save_templateAInspect

Save the current (reviewed) field layout as a reusable template.

Next time this exact PDF is opened — by you or another agent session on this account — open_pdf returns these fields with confidence 1.0 and no ML pass at all. This is what makes repeat filling deterministic.

Before saving, give every field a short semantic name (update_fields with name=..., e.g. 'age_score', 'total_abcd2') — names are stored in the template, so the next session maps values by meaning instead of guessing from coordinates. Also remove false positives first (remove_fields).

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior4/5

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

With no annotations, description explains behavioral impacts: templates cause open_pdf to return fields with confidence 1.0 and skip ML, making filling deterministic. Does not mention overwriting behavior.

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?

Multi-sentence description is informative with no redundancy. Each sentence adds value, though could be slightly more concise.

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 one parameter and an output schema (though not shown), the description adequately covers the tool's purpose and behavior without missing critical details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has only one parameter 'name' with 0% description coverage. Description does not elaborate on the meaning or format of the name, beyond implying it identifies the template.

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 saves the current field layout as a reusable template. It uses specific verb 'save' and resource 'template', differentiating from sibling tools like list_templates.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit instructions on prerequisites: name fields and remove false positives before saving. Explains benefit (deterministic fill) but lacks explicit alternatives or when-not-to-use.

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

update_fieldCInspect

Move/resize/rename a field, or set its text alignment.

align: 'left'|'center'|'right'; vertical_align: 'top'|'middle'|'bottom' — where the value sits inside the box in the filled PDF.

ParametersJSON Schema

Name	Required	Description	Default
`h`	No
`w`	No
`x`	No
`y`	No
`name`	No
`align`	No
`field_id`	Yes
`field_type`	No
`vertical_align`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, so the description carries full burden. It indicates mutation (move/resize/rename) but does not disclose side effects, permissions, or whether changes are saved. Lacks behavioral depth.

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?

Description is very concise (2 sentences), front-loads the main purpose, and provides specific alignment details without waste. Could be slightly more structured but remains efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 9 parameters and 0% schema coverage, the description is incomplete. It fails to explain all parameters, required field_id, or output behavior, despite an output schema being present.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so description must compensate. It explicitly explains align and vertical_align with allowed values. However, it does not explain x, y, h, w, name, or field_type, leaving many parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool moves/resizes/renames a field or sets text alignment, specifying the resource and actions. It distinguishes from add_field and remove_field but does not differentiate from update_fields (plural).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives like update_fields or remove_field. No when-to-use or when-not-to-use statements provided.

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

update_fieldsAInspect

Update many fields in one call (batch version of update_field).

Each item: {"field_id": "...", and any of x, y, w, h, name, field_type, align, vertical_align}. Items with an unknown field_id are reported back, the rest are still applied.

ParametersJSON Schema

Name	Required	Description	Default
`updates`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

Discloses partial success behavior and item structure, but lacks details on permissions, side effects, or error types.

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?

Two concise sentences, no redundancy, front-loaded purpose.

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?

Output schema exists, so return values not needed. Description covers parameter structure and distinguishes from sibling tools. However, could mention when not to use it more explicitly.

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 no description (0% coverage), but description specifies allowed fields for each item (x,y,w,h,name,field_type,align,vertical_align), compensating well.

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 it's a batch version of update_field, with verb 'update' and resource 'fields'. Distinguishes from sibling update_field.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies when to use (batch updates) vs update_field (single). Also explains partial failure behavior with unknown field_ids.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

1 tool updatev0.4.6Jul 29, 2026
- Addedclose_workspace
13 tool updatesv0.4.3Jul 8, 2026
- First observedadd_field
- First observedfill_pdf
- First observedlist_fields
- First observedlist_templates
- First observedopen_pdf
- First observedprune_fields
- First observedremove_field
- First observedremove_fields
- First observedrender_filled_preview
- First observedrender_preview
- First observedsave_template
- First observedupdate_field
- First observedupdate_fields

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

Disambiguation5/5

Each tool has a clear, distinct purpose. Despite multiple tools for field removal and update, they differentiate by batch/single/targeted criteria. Preview tools are separated by whether they show boxes or filled content. No two tools are ambiguous.

Naming Consistency5/5

All tools use consistent snake_case with verb_noun pattern (e.g., remove_fields, fill_pdf, list_templates). Batch versions are indicated by plural nouns (fields vs field), which is intuitive. No mixing of styles.

Tool Count5/5

14 tools cover the full workflow of PDF form filling: opening, detection, field manipulation, templates, preview, fill, and cleanup. This is well-scoped for the domain without being excessive or sparse.

Completeness4/5

The tool surface covers the main lifecycle: open, detect, add/remove/update fields, preview, fill, save templates, and close. Minor gaps: no explicit retrieval of the output PDF path or deletion of templates, but these are not critical for the core filling task.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

iFillPDFOAuth
com.ifillpdf
Detect fillable fields in any PDF with AI, scans included, then fill and sign it.
AI & Machine Learning File Systems
2
PDF Kit B
com.hellobasestation
AI-powered PDF tools: fill forms via natural language
App Automation Documentation Access
12
emboss
io.github.edwinorange
Turn flat PDFs into fillable forms and fill them from data, documents, or a spreadsheet.
App Automation Workplace & Productivity
1
Document to JSON – PDF Invoice/Statement/Contract ParserOAuth
io.github.fashionmascherine-svg
Turn any PDF into structured JSON via AI + OCR: invoices, bank statements, contracts.
Finance AI & Machine Learning
28

Related MCP Servers

formfill-mcp
App Automation File Systems
knportal
A
license
Not graded
quality
F
maintenance
FormFill MCP — AI-powered web form automation. Fill out any online form by describing what you want. Supports Stripe payments via x402 protocol.
Updated 3 months ago (2026-06-11 14:19 UTC)
3
MIT
pdf-filler-mcp
File Systems
patroqueeet
A
license
Not graded
quality
D
maintenance
Enables filling any PDF form, including scanned or AcroForm, through a browser-based drag-and-drop editor. Works entirely locally with no data leaving the machine.
Updated 6 months ago (2026-02-21 22:00 UTC)
MIT
pdfops-mcpofficial
Developer Tools File Systems Workplace & Productivity
pdfops
A
license
A
quality
A
maintenance
AI agents can inspect, fill, merge PDFs, and generate invoices deterministically using local file paths, without PDF bytes passing through the model context.
Updated 9 days ago (2026-08-27 21:14 UTC)
5
335
MIT
formasty
App Automation Marketing Workplace & Productivity
QuantumCoderSys
A
license
Not graded
quality
A
maintenance
Enables AI agents to build and operate production-ready forms, quizzes, surveys, and workflows, including creation, publishing, submission management, and integration with webhooks and analytics.
Updated 19 days ago (2026-08-18 16:54 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/mrmaciej1/justfill-mcp'

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

JustFill MCP Server

Excel or CSV batch workflow

Import-ready n8n workflows

Business example: recurring supplier intake

Gemini CLI extension

Why agents can trust it

Setup

Tools

Example agent flow

Notes

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

pdfops-mcpofficial

Latest Blog Posts

MCP directory API