Skip to main content
Glama

add_table

Create and insert a table into a Word document by specifying rows, columns, and optional data. Simplifies document formatting for structured content.

Instructions

Add a table to a Word document.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
colsYes
dataNo
filenameYes
rowsYes

Implementation Reference

  • Core handler function that implements the add_table tool logic: validates inputs, loads the document, creates a table with specified dimensions, optionally populates it with data, applies 'Table Grid' style if available, and saves the document.
    async def add_table(filename: str, rows: int, cols: int, data: Optional[List[List[str]]] = None) -> str:
        """Add a table to a Word document.
        
        Args:
            filename: Path to the Word document
            rows: Number of rows in the table
            cols: Number of columns in the table
            data: Optional 2D array of data to fill the table
        """
        filename = ensure_docx_extension(filename)
        
        if not os.path.exists(filename):
            return f"Document {filename} does not exist"
        
        # Check if file is writeable
        is_writeable, error_message = check_file_writeable(filename)
        if not is_writeable:
            # Suggest creating a copy
            return f"Cannot modify document: {error_message}. Consider creating a copy first or creating a new document."
        
        try:
            doc = Document(filename)
            table = doc.add_table(rows=rows, cols=cols)
            
            # Try to set the table style
            try:
                table.style = 'Table Grid'
            except KeyError:
                # If style doesn't exist, add basic borders
                pass
            
            # Fill table with data if provided
            if data:
                for i, row_data in enumerate(data):
                    if i >= rows:
                        break
                    for j, cell_text in enumerate(row_data):
                        if j >= cols:
                            break
                        table.cell(i, j).text = str(cell_text)
            
            doc.save(filename)
            return f"Table ({rows}x{cols}) added to {filename}"
        except Exception as e:
            return f"Failed to add table: {str(e)}"
  • MCP tool registration using FastMCP @mcp.tool() decorator. Defines the tool schema via function signature and docstring, and delegates execution to the core handler in content_tools.
    async def add_table(filename: str, rows: int, cols: int, data: Optional[List[List[str]]] = None):
        """Add a table to a Word document."""
        return await content_tools.add_table(filename, rows, cols, data)
  • Tool schema defined by the function parameters (filename: str, rows: int, cols: int, data: Optional[List[List[str]]]) and docstring in the MCP registration.
    async def add_table(filename: str, rows: int, cols: int, data: Optional[List[List[str]]] = None):
        """Add a table to a Word document."""
        return await content_tools.add_table(filename, rows, cols, data)
  • Central import/export of content tools including add_table, facilitating access for the main server registration.
    from word_document_server.tools.content_tools import (
        add_heading, add_paragraph, add_table, add_picture,
        add_page_break, add_table_of_contents, delete_paragraph,
        search_and_replace
    )
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states the action ('Add') but doesn't describe what happens—e.g., whether it modifies the document in-place, requires specific permissions, handles errors, or what the output looks like. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.

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, direct sentence with zero waste—it states the core action and resource without fluff. It's appropriately sized for a simple tool and front-loaded with essential information, making it highly efficient.

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?

Given the tool's complexity (a mutation with 4 parameters), lack of annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like side effects, error handling, or return values, nor does it clarify parameter meanings. For a tool that modifies documents, this leaves critical gaps for an agent.

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 must compensate for undocumented parameters. It mentions adding a table but doesn't explain what 'filename', 'rows', 'cols', or 'data' mean in context—e.g., 'filename' likely refers to the target document, 'rows' and 'cols' define table dimensions, and 'data' might populate cells. Without this, parameter understanding is incomplete.

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 action ('Add') and resource ('table to a Word document'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'add_paragraph' or 'add_picture' by specifying the type of content being added. However, it doesn't explicitly mention what distinguishes it from 'format_table' or 'modify_table_cell', which keeps it from a perfect score.

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. It doesn't mention prerequisites (e.g., document must exist), when not to use it (e.g., for modifying existing tables), or direct alternatives among siblings like 'format_table' for existing tables. This leaves the agent with minimal contextual direction.

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

Related 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/franlealp1/mcp-word'

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