Skip to main content
Glama
nometalalchemist

io.github.nometalalchemist/kitchensink4xl

modify_grid_structure

Insert or delete rows or columns and automatically rewrite every formula, defined name, validation, conditional format, table, and merged range so the workbook stays coherent.

Instructions

Insert or delete rows or columns at a position and REWRITE EVERY REFERENCE so the workbook stays coherent: formulas on every sheet (cross-sheet refs included), defined names, data validations, conditional-format ranges, table refs, and merged ranges all shift with the edit. action is insert_rows, delete_rows, insert_cols, or delete_cols; at is the 1-based row number or column letter where the edit starts (a cell like 'B7' or a location object also works, using its top-left); count edits that many at once.

Whole-column spans like =SUM(B:B) and whole-row spans like $1:$2 shift on their own axis; an edit on the other axis leaves them alone (Excel's behavior). A reference wholly inside a deleted band becomes #REF! and the new-#REF! count is reported, never hidden; an insert that would push value-bearing cells off the grid edge refuses. Returns per-kind rewrite counts. A hazardous workbook refuses unless allow_loss is true. Auto-backup: prev/anchor slots in .ks4xl-backups (backup=false skips rotation); atomic verified save, restored on failed verify; the prev slot is the undo for a delete. Refuses while open in Excel.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
atYes
pathYes
countNo
sheetNo
actionYes
backupNo
allow_lossNo
verify_comNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observedv1.0.0

TDQS

A4.4/5.0
Behavior5/5

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

No annotations exist, so the description carries the full burden of behavioral disclosure. It reveals major side effects: every reference type shifts, deleted references become #REF!, edge-pushing inserts refuse, backups are rotated, saves are atomic and verified, and Excel-lock refusal occurs. This is exceptional 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 long but every clause carries distinct operational meaning. It is front-loaded with the core purpose, then parameter semantics, then edge cases and safety behavior. There is no filler or repetition.

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 annotations, the description is remarkably complete: it covers reference rewrites, failure modes, loss prevention, backup behavior, and response counts. The only notable omission is clarification for verify_com and sheet, but the overall context is sufficient 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 coverage is 0%, so the description must compensate. It does explain action, at, count, backup, and allow_loss meaningfully. However, path, sheet, and especially verify_com are not described; verify_com is opaque from the property name alone. The description partially compensates but leaves gaps for some optional parameters.

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 names a specific verb and resource: inserting or deleting rows/columns with full reference rewriting. This clearly distinguishes it from sibling tools like set_cells, apply_edits, or set_dimensions. The scope is explicit and unambiguous.

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 makes clear when the tool is appropriate: any structural row/column insertion or deletion that must keep the workbook coherent. It also states refusal conditions, such as hazardous workbooks requiring allow_loss and Excel-open refusal. It does not explicitly name alternative sibling tools, but the use case is well bounded.

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

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/nometalalchemist/KitchenSink4XL'

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