Google Workspace MCP Server - Control Gmail, Calendar, Docs, Sheets, Slides, Chat, Forms & Drive

Create Table with Data

create_table_with_data

Create a table in Google Docs and populate it with your data. Specify the document, position, and a 2D array of strings to insert a formatted table in one operation.

Instructions

Creates a table and populates it with data in one reliable operation.

CRITICAL: YOU MUST CALL inspect_doc_structure FIRST TO GET THE INDEX!

MANDATORY WORKFLOW - DO THESE STEPS IN ORDER:

Step 1: ALWAYS call inspect_doc_structure first Step 2: Use the 'total_length' value from inspect_doc_structure as your index Step 3: Format data as 2D list: [["col1", "col2"], ["row1col1", "row1col2"]] Step 4: Call this function with the correct index and data

EXAMPLE DATA FORMAT: table_data = [ ["Header1", "Header2", "Header3"], # Row 0 - headers ["Data1", "Data2", "Data3"], # Row 1 - first data row ["Data4", "Data5", "Data6"] # Row 2 - second data row ]

CRITICAL INDEX REQUIREMENTS:

NEVER use index values like 1, 2, 10 without calling inspect_doc_structure first
ALWAYS get index from inspect_doc_structure 'total_length' field
Index must be a valid insertion point in the document

DATA FORMAT REQUIREMENTS:

Must be 2D list of strings only
Each inner list = one table row
All rows MUST have same number of columns
Use empty strings "" for empty cells, never None
Use debug_table_structure after creation to verify results

Input Schema

TableJSON Schema

Name	Required	Description
`index`	Yes	Document position (MANDATORY: get from inspect_doc_structure 'total_length')
`tab_id`	No	Optional tab ID to create the table in a specific tab
`table_data`	Yes	2D list of strings - EXACT format: [["col1", "col2"], ["row1col1", "row1col2"]]
`document_id`	Yes	ID of the document to update
`header_rows`	No	Number of leading rows to mark as a repeating header that reappears after each page break. Must be between 0 and the number of table rows (default: 0 = none)
`bold_headers`	No	Whether to make first row bold (default: true)
`user_google_email`	Yes	User's Google email address

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.28.0Sep 24, 2026
- removedInput schema / properties / tab_id / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / tab_id / type
```
Added value: +"string"
```
Addedv1.0.1Jul 31, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already establish read-only false and non-destructive, so the description need not restate that. It adds real behavioral constraints: the index must come from inspect_doc_structure, rows must be uniform, and debug_table_structure should be used after creation to verify. It does not explain failure modes, but the bar is lower because annotations cover the safety profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded and uses numbered sections, but it is repetitive: the CRITICAL index requirement is stated three times, and the workflow repeats the data-format details already in the schema. It earns its place mostly, but could be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is very complete for an agent: it supplies the mandatory upstream call, the index source, data format rules, and post-creation verification via debug_table_structure. It stops short of discussing output/return shape or failure handling, but the presence of an output schema reduces that burden.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the exact 2D array shape, the no-None rule, uniform column counts, and the mandatory relationship between index and inspect_doc_structure.total_length.

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 opening sentence names the exact operation ('Creates a table and populates it with data') and highlights the one-call atomicity. This distinguishes it from append_table_rows and insert_doc_elements in the sibling list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives a mandatory step-by-step workflow: call inspect_doc_structure first, derive the index from total_length, then call this function. It lacks explicit when-not-to-use or alternative tool routing, but the precondition and order are unambiguous.

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

Deploy Server