Skip to main content
Glama
KitchenSink4AI

io.github.nometalalchemist/kitchensink4xl

by KitchenSink4AI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Set Cells

set_cells
DestructiveIdempotent

Write multiple Excel cells in one atomic operation, resolving all addresses first to prevent partial writes. Supports formulas, auto-backup, and safe refusal when data loss would occur.

Instructions

Write many individually addressed cells as ONE atomic batch, the scatter complement to write_range. cells is a list of {cell, value} items (cell is an A1 string or a location object resolving to one cell; 1,000-cell ceiling); every address is resolved BEFORE anything is written, so one bad item refuses the whole batch untouched. '=' strings become formulas, normalized. A hazardous workbook refuses unless allow_loss is true. Auto-backup to .ks4xl-backups; atomic verified save. Refuses while open in Excel.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
cellsYesScatter writes, {cell, value}; every address resolves before anything is written.
sheetNo
backupNo
allow_lossNo
verify_comNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.0
    • changedOutput schema / (root)
      Previous value: -{
-  "additionalProperties": true,
-  "type": "object"
-}New value: +null
  2. Changed4 schema fields changedv1.1.0
    • addedInput schema / properties / cells / description
      Added value: +"Scatter writes, {cell, value}; every address resolves before anything is written."
    • addedInput schema / properties / cells / items / properties
      Added value: +{
+  "cell": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "object"
+      }
+    ]
+  },
+  "value": {
+    "anyOf": [
+      {
+        "type": "string"
+      },
+      {
+        "type": "number"
+      },
+      {
+        "type": "boolean"
+      },
+      {
+        "type": "null"
+      }
+    ],
+    "description": "A cell value: text, a number, a boolean, or null to clear. A string beginning with '=' is stored as a formula."
+  }
+}
    • addedInput schema / properties / cells / items / required
      Added value: +[
+  "cell"
+]
    • addedInput schema / properties / cells / items / type
      Added value: +"object"
  3. First observedv1.0.0

TDQS

A4.1/5.0
Behavior5/5

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

The description goes far beyond the annotations. It reveals atomicity, resolution-before-write behavior, the 'one bad item refuses the whole batch untouched' failure mode, formula normalization, the hazardous-workbook gate via allow_loss, auto-backup, atomic verified save, and the refusal to run while the file is open in Excel. This gives an agent a rich, accurate behavioral model.

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 dense and front-loaded, opening with the core purpose before diving into constraints and safeguards. Every sentence adds specific value, though the amount of detail makes it slightly long. It is well-organized and free of fluff.

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?

For a complex mutation tool with no output schema and six parameters, the description covers the most critical operational aspects: atomicity, failure semantics, formula handling, hazard gating, backup, and Excel lock behavior. It does not explain sheet selection, the backup parameter's role, or verify_com, which leaves some gaps, but overall it is sufficiently complete for safe invocation.

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 very low (17%), so the description must compensate. It does add meaning for the cells parameter (structure, cell format, 1,000-cell ceiling) and for allow_loss (hazardous workbook gate). However, key parameters like path, sheet, backup, and verify_com are left unexplained, leaving noticeable gaps.

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 states the verb ('Write'), the resource ('many individually addressed cells'), and the key constraint ('ONE atomic batch'). It also explicitly frames the tool as the 'scatter complement to write_range', which immediately distinguishes it from the sibling range-writing tool and implies it is the batch version of set_cell.

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

Usage Guidelines3/5

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

Mentioning 'scatter complement to write_range' gives contextual guidance for when to choose this over write_range, but it does not explicitly state when not to use it or name alternatives like set_cell for single-cell writes. The guidance is implied rather than explicit, so it falls short of a clear usage rule.

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