form fill-mcp
Server Details
Fill any PDF form from your AI agent — in a single tool call.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 5 of 5 tools scored. Lowest: 3.5/5.
Each tool has a distinct purpose: extracting data, filling (with two variants based on page count), flattening, and listing fields. The descriptions clearly differentiate when to use each fill tool, ensuring an agent can reliably select the correct one.
All tool names follow a consistent verb_noun pattern using snake_case (extract_form_data, fill_form, fill_form_multipage, flatten_form, list_form_fields), making the tool set predictable and easy to navigate.
With exactly 5 tools, the server is well-scoped for the domain of PDF form filling. Each tool covers a necessary step in the workflow, and there is no bloat or insufficiency.
The tool set covers the full lifecycle: inspection (list_form_fields), filling (for short and long forms), extraction (extract_form_data), and flattening (flatten_form). No obvious gaps like validation or creation are expected given the server's focused purpose.
Available Tools
5 toolsextract_form_dataAInspect
Extract all form field values from a filled PDF form. Returns a dict mapping field names to their current values. Price: $0.001 USDC per call.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | Your FormFill API key (get one at formfill.plenitudo.ai). | |
| pdf_path | Yes | Absolute path to the PDF file on disk. | |
| payment_proof | No | x402 payment proof (tx hash). Alternative to api_key for pay-per-use. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context about the return format (dict mapping) and pricing ('Price: $0.001 USDC per call'), but lacks details on permissions, rate limits, error handling, or whether the operation is read-only (implied but 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with three sentences: purpose, output, and pricing. It's front-loaded with the core functionality, though the pricing detail might be less critical upfront. No wasted words, but minor structural improvement could prioritize usage context over pricing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (extraction from PDFs), 100% schema coverage, and the presence of an output schema (implied by 'Returns a dict'), the description is mostly complete. It covers purpose and output format well, but lacks usage guidelines and some behavioral details like error cases, making it slightly incomplete for optimal agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all three parameters (pdf_path, api_key, payment_proof) with their purposes. The description adds no additional parameter semantics beyond what the schema provides, maintaining the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Extract all form field values'), target resource ('from a filled PDF form'), and output format ('Returns a dict mapping field names to their current values'). It distinguishes itself from siblings like fill_form or list_form_fields by focusing on extraction rather than modification or listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 doesn't mention sibling tools like list_form_fields (which might list fields without values) or flatten_form (which might modify the PDF), nor does it specify prerequisites such as requiring a pre-filled PDF form.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fill_formAInspect
Fill a PDF form with the given field values and save the result to disk.
WORKFLOW: 1) Call list_form_fields first to get exact field names and their x/y positions.
2) Use position coordinates to confirm which field is which — higher y = higher on page.
3) Pass exact field names from list_form_fields here. Never guess field names.
Use for single-page or short forms (under 5 pages). Use fill_form_multipage for longer forms.
Returns ok:false with unknown_fields if ALL provided field names are invalid.
Returns ok:true with a warnings.unknown_fields list if SOME names are invalid (partial fill).| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | Your FormFill API key (get one at formfill.plenitudo.ai). | |
| pdf_path | Yes | Absolute path to the source PDF file. | |
| output_path | Yes | Absolute path where the filled PDF will be saved. | |
| field_values | Yes | Map of field names to values. Use list_form_fields to discover field names. | |
| payment_proof | No | x402 payment proof (tx hash). Alternative to api_key for pay-per-use. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses return behavior (ok:false/ok:true with warnings), but does not mention potential side effects like overwriting existing files. However, it covers error conditions well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points (WORKFLOW, usage notes, return behavior). Every sentence serves a purpose. Efficiently conveys required steps and constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (5 params, output schema, nested objects), the description covers workflow, error cases, sibling distinction, and return behavior. Sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds meaningful workflow context: field_values should be discovered via list_form_fields, api_key vs payment_proof alternative. This adds value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Fill a PDF form') and resource ('with the given field values and save the result to disk'). It distinguishes the tool from sibling 'fill_form_multipage' by stating usage for single-page/short forms, and references 'list_form_fields' for field discovery.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit workflow: call list_form_fields first, use position coordinates, pass exact field names. Clearly states when to use this tool vs 'fill_form_multipage'. Also explains error return behavior for invalid fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fill_form_multipageAInspect
Fill a multi-page PDF form, iterating page-by-page for reliability.
WORKFLOW: 1) Call list_form_fields first to get exact field names and their x/y positions.
2) Use position coordinates to confirm which field is which — higher y = higher on page.
3) Pass exact field names from list_form_fields here. Never guess field names.
Use when the PDF has more than 5 pages or fields spanning multiple pages (rental applications,
tax packets, multi-section HR forms). Prefer this over fill_form for any complex/long document.
Returns ok:false with unknown_fields if ALL provided field names are invalid.
Returns ok:true with a warnings.unknown_fields list if SOME names are invalid (partial fill).| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | Your FormFill API key (get one at formfill.plenitudo.ai). | |
| pdf_path | Yes | Absolute path to the source PDF file. | |
| output_path | Yes | Absolute path where the filled PDF will be saved. | |
| field_values | Yes | Map of field names to values. Use list_form_fields to discover field names. | |
| payment_proof | No | x402 payment proof (tx hash). Alternative to api_key for pay-per-use. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully covers behavior. It details return states (ok:false with unknown_fields if all fields invalid, ok:true with warnings.unknown_fields if partial fill). It does not mention if the original file is modified, but this is implied by 'fill'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with purpose first, then workflow, usage, and return behavior. It is efficient but not minimal; could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multi-page, 5 params, output schema exists), the description is complete. It covers prerequisite steps, success/failure modes, and usage context without needing to explain return values since output schema is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds some context (e.g., field_values should come from list_form_fields, api_key vs payment_proof alternatives) but does not significantly expand beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fills multi-page PDF forms, with a specific verb and resource. It distinguishes from fill_form by specifying it's for complex or long documents with fields across pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit workflow is provided: call list_form_fields first, use coordinates, pass exact field names. It explains when to use (more than 5 pages or fields spanning pages) and implies alternatives (fill_form for simple cases). Also covers error behavior for invalid fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
flatten_formAInspect
Flatten a filled PDF form so form fields become non-editable static content. Returns success status and output path. Price: $0.001 USDC per call.
| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | Your FormFill API key (get one at formfill.plenitudo.ai). | |
| pdf_path | Yes | Absolute path to the source PDF file. | |
| output_path | Yes | Absolute path where the flattened PDF will be saved. | |
| payment_proof | No | x402 payment proof (tx hash). Alternative to api_key for pay-per-use. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing key behavioral traits: it specifies the transformation (making fields non-editable), mentions the return format ('success status and output path'), and includes critical cost information ('Price: $0.001 USDC per call'). However, it doesn't cover error conditions or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly front-loaded with the core purpose in the first sentence, followed by return values and pricing in subsequent sentences. Every sentence earns its place with zero wasted words, making it highly efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (PDF transformation with payment), no annotations, 100% schema coverage, and presence of an output schema, the description provides excellent contextual completeness. It covers what the tool does, what it returns, and critical cost information, making it fully adequate for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 4 parameters thoroughly. The description adds no additional parameter information beyond what's in the schema, maintaining the baseline score of 3 for adequate but no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Flatten a filled PDF form') and the transformation effect ('so form fields become non-editable static content'), distinguishing it from sibling tools like extract_form_data or fill_form which handle form data extraction or population rather than making forms non-editable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to make PDF form fields non-editable, but provides no explicit guidance on when to use this tool versus alternatives like fill_form (which modifies fields) or list_form_fields (which inspects them). No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_form_fieldsAInspect
Inspect a PDF and return every fillable field: name, type, current value, and x/y position on the page.
ALWAYS call this before fill_form. Use the exact field names returned here — never guess.
Use the position coordinates (x, y) to identify what each field represents visually:
higher y = higher on the page in PDF coordinates. Fields with similar y values are on
the same horizontal line; fields with similar x values are in the same column.
The response also includes pdf_type so you know if the PDF may have rendering quirks.| Name | Required | Description | Default |
|---|---|---|---|
| api_key | No | Your FormFill API key (get one at formfill.plenitudo.ai). | |
| pdf_path | Yes | Absolute path to the PDF file on disk. | |
| payment_proof | No | x402 payment proof (tx hash). Alternative to api_key for pay-per-use. |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return data (fields, position, pdf_type) and explains coordinate system behavior. It does not mention side effects (which are minimal as a read operation), authorization, or error states, but the key behaviors are well-covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is five sentences, front-loaded with the main purpose, followed by critical usage instruction, coordinate interpretation, and an additional note about pdf_type. Every sentence provides distinct value, and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description appropriately focuses on high-level return components and usage context. It covers the prerequisite relationship with fill_form, coordinate interpretation, and mentions pdf_type for edge cases. For an inspection tool with a rich schema, this is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description does not elaborate on parameters beyond the overall purpose; the schema already documents them adequately. The description adds no new semantic details for the parameters, so it meets the baseline without exceeding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Inspect a PDF and return every fillable field: name, type, current value, and x/y position on the page.' This is a specific verb-resource pair that differentiates it from sibling tools like fill_form or flatten_form.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'ALWAYS call this before fill_form' and instructs to use exact field names, providing strong workflow guidance. It also explains coordinate interpretation. However, it does not address when to use other siblings like extract_form_data or flatten_form, missing some comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!