Skip to main content
Glama

insert_image

Add images to Word documents by specifying file paths and optional dimensions to enhance document content with visual elements.

Instructions

Insert an image into a document.

Args: filepath: Path to the document image_path: Path to the image file to insert width: Image width in inches (optional) height: Image height in inches (optional)

Returns: Dictionary with status

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filepathYes
image_pathYes
widthNo
heightNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The `insert_image` function is defined and registered as an MCP tool using the `@app.tool()` decorator in `src/docx_mcp/server.py`. It handles the logic of validating the image path, opening the Word document, adding the image to a new paragraph, and saving the document.
    def insert_image(
        filepath: str,
        image_path: str,
        width: Optional[float] = None,
        height: Optional[float] = None,
    ) -> dict[str, Any]:
        """
        Insert an image into a document.
    
        Args:
            filepath: Path to the document
            image_path: Path to the image file to insert
            width: Image width in inches (optional)
            height: Image height in inches (optional)
    
        Returns:
            Dictionary with status
        """
        logger.info("Inserting image", extra={"tool": "insert_image", "filepath": filepath})
    
        try:
            # Validate image file exists
            if image_path.endswith(('.docx', '.doc', '.dotx', '.dot')):
                image_file = validate_docx_file(image_path)
            else:
                image_file = Path(image_path)
            if not image_file.exists():
                raise DocxFileNotFoundError(image_path)
    
            doc = safe_open_document(filepath)
    
            # Add paragraph with image
            last_paragraph = doc.add_paragraph()
            run = last_paragraph.add_run()
    
            # Insert image with optional sizing
            if width and height:
                run.add_picture(str(image_file), width=Inches(width), height=Inches(height))
            elif width:
                run.add_picture(str(image_file), width=Inches(width))
            elif height:
                run.add_picture(str(image_file), height=Inches(height))
            else:
                run.add_picture(str(image_file))
    
            safe_save_document(doc, filepath)
            logger.info("Image inserted successfully", extra={"filepath": filepath})
    
            return {
                "status": "success",
                "filepath": filepath,
                "image": image_path,
                "message": "Image inserted successfully",
            }
        except DocxMcpError as e:
            logger.warning(e.message, extra={"tool": "insert_image", "error_code": e.error_code})
            return {"status": "error", "error": e.message, "error_code": e.error_code}
        except Exception as e:
            logger.error(f"Unexpected error inserting image: {str(e)}")
            return {"status": "error", "error": str(e)}
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 mentions the tool 'inserts' an image, implying a write/mutation operation, but doesn't disclose important behavioral traits like: what happens if the document doesn't exist, whether the insertion is destructive to existing content, what permissions are needed, or how errors are handled. The return value mention is minimal.

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?

The description is appropriately sized and front-loaded with the core purpose. The Args/Returns structure is clear, though the return description ('Dictionary with status') is somewhat vague. No unnecessary sentences or fluff.

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 4 parameters with 0% schema coverage and no annotations, the description provides basic parameter semantics but lacks behavioral context. The output schema exists (though unspecified), reducing the need to detail return values. However, for a mutation tool with multiple siblings, more guidance on usage and error conditions would improve completeness.

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 the description must compensate. It provides basic semantic meaning for all parameters (filepath, image_path, width, height) and indicates which are optional. However, it doesn't explain path formats (absolute/relative), valid width/height ranges, units beyond 'inches', or what happens when only one dimension is provided.

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 verb ('insert') and resource ('image into a document'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'add_image_caption' or 'extract_images', which might have overlapping functionality with images in documents.

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. With siblings like 'add_image_caption' (which might handle captioned images) and 'extract_images' (which removes images), there's clear potential for confusion about which tool to use for different image-related document operations.

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

Install Server

Other Tools

Latest Blog Posts

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/Andrew82106/LLM_Docx_Agent_MCP'

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