KitchenSink4Word

Overview Schema Source Related Servers Discussions Admin

Create Table

create_table

Create a Word table from 2D string data with single-line borders and a bold repeating header. Optionally set width, position, and backup.

Instructions

Create a table from 2D string data with single-line borders and a bold repeating header row (header_row=False for none). location is the standard location object; omit it to append at the end; position 'after' only. Shading, column widths and repeat-header on an EXISTING table: format_cells and set_table_properties (media-forms). From a CSV or JSON file: import_table (protection-io pack). Auto-backup: prev/anchor slots in .ks4w-backups (backup=False skips rotation only); atomic save. Refuses documents open in Word.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`data`	Yes
`backup`	No
`location`	No
`width_pt`	No
`file_path`	Yes
`header_row`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv2.0.0Sep 4, 2026

removedInput schema / properties / after_anchor

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null
-}

removedInput schema / properties / after_index

Removed value: -{
-  "anyOf": [
-    {
-      "type": "integer"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null
-}

removedInput schema / properties / at_end

Removed value: -{
-  "default": false,
-  "type": "boolean"
-}

addedInput schema / properties / location

Added value: +{
+  "anyOf": [
+    {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null
+}

First observedv1.2.1Aug 27, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only carry false hints that this is not read-only and not open-world, so the description shoulders the behavioral burden. It discloses auto-backup rotation slots (prev/anchor in .ks4w-backups), the exact meaning of backup=False (skips rotation only), atomic save behavior, and refusal to operate on Word-open documents.

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?

Every sentence delivers a distinct piece of information: core behavior, location semantics, sibling routing, backup behavior, and the Word-open constraint. It is dense yet well-structured and front-loaded with the primary purpose.

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 covers the decision-relevant distinctions, location semantics, and safety/backup behavior well for a 6-parameter tool with no schema-level param descriptions. The only notable gap is the unexplained width_pt parameter, but the parameter name and surrounding context make it inferable enough for a competent agent.

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?

With 0% schema description coverage, the description adds meaningful semantics for data, header_row, location, and backup. However, width_pt is never mentioned, and file_path is left to name inference, so the compensation is excellent but incomplete.

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 opens with a specific verb and resource: 'Create a table from 2D string data' with explicit formatting defaults. It also distinguishes itself from format_cells, set_table_properties, and import_table by naming what each sibling is for, so an agent can tell it apart without ambiguity.

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

Usage Guidelines5/5

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

It explicitly routes to alternatives: format_cells/set_table_properties for existing tables and import_table for CSV/JSON files. It also states the location rule (only 'after', omit to append) and the Word-open refusal condition, giving clear when-to-use and when-not-to-use guidance.

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