Skip to main content
Glama
andr3medeiros

PDF Manipulation MCP Server

pdf_fill_form

Fill form fields in PDF documents with specified values to complete digital forms. This tool populates text fields, checkboxes, and other form elements in PDF files.

Instructions

Fill form fields in a PDF with values.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pdf_pathYes
field_valuesYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • Primary handler implementation for the 'pdf_fill_form' tool. Uses PyMuPDF to iterate through PDF pages and widgets, filling form fields matching keys in field_values dictionary based on widget type. Includes input validation, error handling, and saves output to timestamped file. The @mcp.tool() decorator handles registration and schema inference from type hints and docstring.
    @mcp.tool()
    async def pdf_fill_form(
        pdf_path: str,
        field_values: Dict[str, Any]
    ) -> str:
        """Fill form fields in a PDF with values."""
        if not os.path.exists(pdf_path):
            return f"Error: PDF file not found: {pdf_path}"
        
        if not validate_pdf_file(pdf_path):
            return f"Error: Invalid PDF file: {pdf_path}"
        
        try:
            # Open PDF document
            doc = fitz.open(pdf_path)
            
            filled_fields = 0
            
            # Fill form fields
            for page_num in range(len(doc)):
                page = doc[page_num]
                widgets = page.widgets()
                
                for widget in widgets:
                    field_name = widget.field_name
                    if field_name in field_values:
                        value = field_values[field_name]
                        
                        # Set field value based on widget type
                        if widget.field_type == fitz.PDF_WIDGET_TYPE_TEXT:
                            widget.field_value = str(value)
                        elif widget.field_type == fitz.PDF_WIDGET_TYPE_CHECKBOX:
                            widget.field_value = bool(value)
                        elif widget.field_type == fitz.PDF_WIDGET_TYPE_RADIOBUTTON:
                            widget.field_value = str(value)
                        elif widget.field_type == fitz.PDF_WIDGET_TYPE_COMBOBOX:
                            widget.field_value = str(value)
                        
                        widget.update()
                        filled_fields += 1
            
            if filled_fields == 0:
                doc.close()
                return "No matching form fields found to fill."
            
            # Generate output filename
            output_path = generate_output_filename(pdf_path)
            
            # Save the modified PDF
            doc.save(output_path)
            doc.close()
            
            return f"Successfully filled {filled_fields} form fields. Output saved to: {output_path}"
            
        except Exception as e:
            return f"Error filling form fields: {str(e)}"
  • Helper function used by pdf_fill_form to validate the input PDF file is valid by attempting to open it with PyMuPDF.
    def validate_pdf_file(pdf_path: str) -> bool:
        """Validate that the file is a valid PDF."""
        try:
            doc = fitz.open(pdf_path)
            doc.close()
            return True
        except Exception:
            return False
  • Helper function used by pdf_fill_form to generate a timestamped output filename to prevent overwriting the original PDF.
    def generate_output_filename(input_path: str, suffix: str = "modified") -> str:
        """Generate a new filename with timestamp to avoid overwriting originals."""
        path = Path(input_path)
        timestamp = datetime.now().strftime("%Y%m%d_%H%M%S")
        return str(path.parent / f"{path.stem}_{suffix}_{timestamp}{path.suffix}")
  • Initialization of the FastMCP server instance. All tools decorated with @mcp.tool() are automatically registered here.
    mcp = FastMCP("pdf-manipulation")

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.0.0
    • addedInput schema / title
      Added value: +"pdf_fill_formArguments"
  2. First observed

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations, the description must carry the full burden of behavioral disclosure. It only states the action and lacks details about field-matching behavior, overwrite semantics, error handling, or any side effects beyond the mutation.

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 a single, front-loaded sentence with no wasted words. It efficiently conveys the core operation without padding.

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, the description does not provide enough context for a tool with a nested object parameter. It fails to explain how to structure field_values or what happens when fields are missing, leaving the agent to guess at critical usage 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 description coverage is 0%, so the description should compensate by explaining parameter meaning. It mentions 'values' but does not clarify that field_values is a mapping of form field names to values, nor does it describe pdf_path beyond the inferred 'PDF' reference.

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 uses a specific verb ('fill') and resource ('form fields in a PDF'), clearly distinguishing it from siblings like pdf_add_form_field or pdf_replace_text. It states exactly what the tool does with no ambiguity.

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 versus alternatives such as pdf_add_form_field or pdf_replace_text. The description implies usage for populating existing form fields but does not state exclusions or context.

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