Fill any PDF form from your AI agent — in a single tool call.
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.
Average 4.3/5 across 5 of 5 tools scored.
Tools are mostly distinct: list_form_fields and extract_form_data read form structure/values, fill_form and fill_form_multipage handle filling with clear usage boundaries, and flatten_form finalizes. The two fill tools share purpose but are explicitly differentiated by document length and complexity.
All tool names follow a consistent verb_noun pattern in snake_case: extract_form_data, fill_form, fill_form_multipage, flatten_form, list_form_fields. The naming clearly indicates the action and target, with no mixed conventions.
Five tools cover the essential PDF form workflow (inspect, read, fill, flatten) without redundancy. The count is well-scoped for the server's purpose.
The tool surface covers the full lifecycle of working with PDF forms: listing fields, extracting data, filling single- or multi-page forms, and flattening. No critical operations are missing for common form-filling scenarios.
extract_form_dataAInspectExtract 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. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return format (dict of field names to values) and cost ($0.001 USDC), but does not mention authentication requirements, error behavior on unfilled forms, or that it only reads the file without modification. The return format and price add some context, but gaps remain.
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?
Two concise sentences cover the action, return format, and pricing. No fluff or repetition; every sentence earns its place.
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?
For a simple read-only extraction tool with an output schema present, the description adequately covers the core behavior and return value. It mentions the pricing and the 'filled PDF' prerequisite. Minor gap: it does not specify what happens with empty or non-form PDFs, but overall it is sufficient 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter description coverage, so the schema already documents all three parameters. The description adds nothing beyond implying that the PDF must be filled, which does not materially enhance parameter understanding. Baseline score of 3 is appropriate.
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 action ('Extract all form field values') and the target resource ('filled PDF form'), which is specific and distinguishes this tool from siblings like fill_form (writing) and list_form_fields (likely just field names).
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 phrase 'from a filled PDF form' implies the tool is for reading values from completed forms, but there is no explicit comparison with sibling tools or guidance on when to use this over list_form_fields. Usage context is implied, not spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fill_formAInspectFill 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. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses return behavior for invalid and partially invalid field names (ok:false with unknown_fields vs ok:true with warnings.unknown_fields), plus the partial fill edge case. This goes beyond basic function and is valuable.
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 a WORKFLOW section, usage limits, and return behavior. It's slightly longer than necessary but every sentence conveys meaningful operational detail. The main purpose is front-loaded.
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 presence of an output schema and rich parameter descriptions, the description adds critical workflow context, alternative tool guidance, and error-handling nuances. It is fully sufficient 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds useful context about using exact field names from list_form_fields and interpreting y-coordinates, but this mostly reinforces existing schema guidance for field_values rather than introducing new parameter semantics.
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 'Fill a PDF form with the given field values and save the result to disk', which is a specific verb+resource. It also distinguishes from siblings by explicitly naming fill_form_multipage for longer forms and 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?
The description provides explicit when-to-use guidance: 'Use for single-page or short forms (under 5 pages). Use fill_form_multipage for longer forms.' It also prescribes a workflow of calling list_form_fields first, including never guessing field names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fill_form_multipageAInspectFill 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. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the page-by-page iteration for reliability and the detailed return behavior: 'Returns ok:false with unknown_fields if ALL provided field names are invalid' and 'Returns ok:true with a warnings.unknown_fields list if SOME names are invalid (partial fill).' It does not mention side effects like overwriting the source file, but the output_path parameter implies a new file is created. This is strong transparency, though not exhaustive.
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 moderately long but well-structured with WORKFLOW, usage, and returns sections. Every sentence earns its place, including the reliability rationale and the partial-fill warning. It is not as tight as a one-liner, but the length is justified by the tool's complexity and the need to steer agents away from guesswork.
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 form filling, 5 params, nested object, output schema), the description is remarkably complete. It explains the prerequisite step (list_form_fields), the coordinate-based field disambiguation, the conditions for preferring this over fill_form, and the exact return behavior for full vs. partial failures. The existence of an output schema lowers the need to describe return values, but the description still provides a useful summary.
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 baseline is 3. The description enriches parameter meaning by instructing how to determine field_values: use list_form_fields to get exact names and x/y positions, and confirm fields via coordinates. It also warns against guessing field names, adding context beyond the schema's own description. This justifies a 4.
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 opens with a specific verb+resource+scope: 'Fill a multi-page PDF form, iterating page-by-page for reliability.' It clearly distinguishes from sibling fill_form by specifying when multi-page is the appropriate choice (more than 5 pages or fields spanning multiple pages). The workflow ties it to list_form_fields, reinforcing its unique role.
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 guidance is given: 'Use when the PDF has more than 5 pages or fields spanning multiple pages' and 'Prefer this over fill_form for any complex/long document.' The WORKFLOW section instructs to call list_form_fields first and never guess field names, providing concrete when-to and when-not-to usage relative to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
flatten_formAInspectFlatten 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. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discloses the key behavioral trait (fields become non-editable static content) and the return value (success status and output path). It also surfaces the cost per call. It does not disclose error handling or edge cases, but the core behavior is 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 three concise sentences covering purpose, return value, and cost. Every sentence adds relevant information with no redundancy or filler.
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?
For a targeted flatten operation with a comprehensive schema and an output schema, the description covers the core action, output, and pricing. It lacks explicit usage guidance (when to use vs. alternatives), but the tool's simplicity and clear schema make the description 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 add additional meaning beyond the schema; it only mentions 'output path' in passing, which is already documented in the schema. No extra semantics are offered.
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 a specific action ('Flatten a filled PDF form') with a precise outcome ('form fields become non-editable static content'). This unambiguously distinguishes it from sibling tools like fill_form or extract_form_data.
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 context by saying 'filled PDF form' (i.e., use after filling), but does not explicitly state when to use this tool versus alternatives, nor any prerequisites or exclusions. It only conveys the action without comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_form_fieldsAInspectInspect 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. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool reads a PDF and returns fields, including position coordinates and pdf_type, which helps the agent anticipate output. However, it doesn't detail failure modes (e.g., password-protected PDFs) or whether the tool modifies anything, but the read-only nature is implied by 'Inspect'.
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: a clear first sentence, then imperative guidance, and explanatory notes. It is slightly long but every sentence adds value (precondition, coordinate interpretation, pdf_type caveat). Not as tight as two sentences, but justified.
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?
The tool has an output schema and rich description that covers purpose, usage, coordinate interpretation, and pdf_type. It lacks explicit preconditions like 'PDF must exist' or error handling, but given the output schema and the guidance provided, it is sufficiently complete for an inspection tool. Sibling tools and the 'ALWAYS call before fill_form' instruction provide good context.
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 the schema already documents pdf_path, api_key, and payment_proof. The description adds context by explaining how to use the returned coordinates but doesn't add much beyond schema for parameters. Baseline 3 is elevated to 4 because the description ties the output to the tool's purpose and gives practical usage hints for the parameters.
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 inspects a PDF and returns every fillable field with name, type, current value, and position. It distinguishes itself from siblings like fill_form by emphasizing this is the inspection/predecessor step. The verb 'Inspect' and specific resource 'fillable field' make the purpose unambiguous.
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?
Explicitly instructs to 'ALWAYS call this before fill_form' and provides guidance on using coordinates to interpret field positions. It also mentions pdf_type for handling rendering quirks. This gives clear when-to-use context and differentiates from fill_form and extract_form_data.
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.
No comments yet. Be the first to start the discussion!
