Skip to main content
Glama
tom275275

Google Workspace MCP Server

by tom275275
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

create_table_with_data

Create a table in a Google Doc and populate it with data in one reliable operation. Provide a 2D array of strings, and the table is inserted at the given index with optional bold headers.

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

Args: user_google_email: User's Google email address document_id: ID of the document to update table_data: 2D list of strings - EXACT format: [["col1", "col2"], ["row1col1", "row1col2"]] index: Document position (MANDATORY: get from inspect_doc_structure 'total_length') bold_headers: Whether to make first row bold (default: true) tab_id: Optional tab ID to create the table in a specific tab

Returns: str: Confirmation with table details and link

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
indexYes
tab_idNo
table_dataYes
document_idYes
bold_headersNo
user_google_emailYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.14.3

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and discloses critical behavior: one reliable operation, a required prerequisite call, index must come from total_length, and verification via debug_table_structure. It does not discuss permissions or failure behavior, but the main behavioral hazards are covered.

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 critical workflow is front-loaded and clearly structured, and the example table_data is valuable. There is some redundancy between the MANDATORY WORKFLOW and CRITICAL INDEX REQUIREMENTS sections, so it is not maximally concise.

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

Completeness5/5

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

For a six-parameter tool with no annotations and no parameter documentation in the schema, the description is complete enough to invoke correctly: it covers prerequisites, exact data formatting, index sourcing, optional parameters, and post-creation verification. The Returns line and output schema cover the response.

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

Parameters5/5

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

Schema description coverage is 0%, and the description compensates thoroughly: table_data is defined with exact 2D-list syntax and row/column rules, index is tied to inspect_doc_structure's total_length, and bold_headers/tab_id are explained. Every parameter receives meaningful semantic context.

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?

States a specific composite operation: creates a table and populates it with data. The tool's niche relative to generic siblings like insert_doc_elements or batch_update_doc is clear from the first sentence.

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?

Gives an explicit mandatory workflow: call inspect_doc_structure first, use its total_length as the index, format data as a 2D list, then call the tool. It does not explicitly name alternative tools or state when not to use this tool, so it misses the top score.

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

Deploy Server

Other Tools