JustFill PDF Form Automation

Request a file-upload link

request_file_upload

Create a one-time upload slot for a PDF (or form photo) when direct file input is unavailable.

For a document on the user's device, or a chat attachment that open_pdf's
`file` parameter cannot carry (the tool call does not accept a file, or the
file arrives without a download_url); tool arguments cannot carry file
bytes reliably. Documents with payment-card data, PHI, government
identifiers, passwords, API keys/tokens, or MFA/OTP codes are not accepted.

Returns `upload_url`, a page where the user opens and drops the file (one
click); `post_url`, which accepts the file as a multipart POST
(`curl -sf -F "file=@document.pdf" <post_url>`) for headless runtimes with
network access to justfill.app (n8n, a server shell; chat sandboxes
usually have none); and `upload_token` for open_pdf. A base64 copy or a
shrunk file is no substitute: modified bytes break detection.

The slot is single-use and expires in 30 minutes.

When to use:
- Use `open_pdf(file=...)` directly if the client passes a chat attachment
  with a `download_url`, or `open_pdf(url=...)` if the file is at a public
  HTTP/HTTPS link.
- Call `request_file_upload` only as a fallback when neither `file` nor `url`
  can deliver the original document, then pass the returned `upload_token` to
  `open_pdf(upload_token=...)`.

Input Schema

Name	Required	Description	Default
No arguments

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Goes well beyond the annotations: discloses that the slot is single-use, expires in 30 minutes, rejects payment-card data, PHI, government IDs, passwords, API keys and MFA/OTP codes, and warns that re-encoded bytes (base64, shrunk files) break detection. Its three return artifacts (upload_url, post_url with a concrete curl example, upload_token) are explained in operational terms. Only gap is that permission/auth requirements for creating the slot are unstated.

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 with the purpose and the fallback condition, then organized into returns and a when-to-use list. It's long, but for a multi-step fallback flow most sentences carry real information. Minor deductions for the awkward mid-sentence line breaks and for restating return values that the output schema already covers.

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?

Annotations cover the safety profile and an output schema exists, yet the description still supplies the failure modes (stale bytes, expired slot, sensitive content) and the exact wiring into open_pdf that an agent needs to complete the flow without trial and error.

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?

Zero parameters, so the schema has nothing to document and the baseline is 4. The description doesn't invent redundant parameter talk and instead spends its words on outputs and gating conditions, which is the right allocation.

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?

States a specific verb and resource — "Create a one-time upload slot for a PDF (or form photo)" — plus the precise condition that gates it: "when direct file input is unavailable." That condition alone separates it from open_pdf and every other sibling in the list.

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?

An explicit "When to use" block names the two preferred paths (open_pdf(file=...) with a download_url, open_pdf(url=...) for a public link) and restricts this tool to the fallback case, then closes the loop by telling the agent to feed the returned upload_token back into open_pdf. Both the when and the when-not are stated, with the alternative tool named.

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

All JustFill PDF Form Automation tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.