Excel MCP Server

Delete rows or columns

delete_rows_or_columns

Destructive

Remove rows or columns from an Excel sheet starting at a specific position. Shifts remaining references, turning links to deleted cells into #REF! errors.

Instructions

Delete rows or columns from start. References move as in insert_rows_or_columns; one to a deleted cell becomes #REF!.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "path": "<path>",
      "sheet": "<sheet>",
      "axis": "<axis>",
      "start": "<start>"
    },
    "name": "delete_rows_or_columns"
  }
}

Input Schema

Name	Required	Description
`axis`	Yes
`path`	Yes
`count`	No
`sheet`	Yes
`start`	Yes	1-based row, or column number (A=1).

Schema Changelog

Changes observed during successful MCP inspections.

Changed14 schema fields changedv2.0.0Oct 13, 2026

removedInput schema / properties / at

Removed value: -{
-  "description": "1-based row number, or 1-based column number (A=1).",
-  "minimum": 1,
-  "title": "At",
-  "type": "integer"
-}

removedInput schema / properties / axis / description

Removed value: -"Whether to act on rows or columns."

removedInput schema / properties / axis / title
```
Removed value: -"Axis"
```
removedInput schema / properties / count / description
```
Removed value: -"How many rows or columns."
```
removedInput schema / properties / count / minimum
```
Removed value: -1
```
removedInput schema / properties / count / title
```
Removed value: -"Count"
```

removedInput schema / properties / path / description

Removed value: -"Path to an .xlsx, .xlsm, .xltx or .xltm file. Relative paths are resolved in the server's workbook directory when one is configured; otherwise use an absolute path."

removedInput schema / properties / path / title
```
Removed value: -"Path"
```
removedInput schema / properties / sheet / description
```
Removed value: -"Worksheet name, e.g. 'Sheet1'."
```
removedInput schema / properties / sheet / title
```
Removed value: -"Sheet"
```

addedInput schema / properties / start

Added value: +{
+  "description": "1-based row, or column number (A=1).",
+  "type": "integer"
+}

changedInput schema / required

Previous value: -[
-  "path",
-  "sheet",
-  "axis",
-  "at"
-]New value: +[
+  "path",
+  "sheet",
+  "axis",
+  "start"
+]

removedInput schema / title

Removed value: -"delete_rows_or_columnsArguments"

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "result": {
-      "title": "Result",
-      "type": "string"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "delete_rows_or_columnsOutput",
-  "type": "object"
-}New value: +null

Addedv1.1.1Sep 29, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the safety profile is covered. The description earns credit by adding behavior beyond annotations: references shift as in insert_rows_or_columns, and references pointing at deleted cells become #REF!. That is genuine, non-obvious consequence disclosure.

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?

Two compact clauses with the core action front-loaded and the side-effect note trailing. Every fragment carries information; no filler. Slightly terse given the surrounding parameter gaps, but structurally sound.

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

Completeness3/5

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

For a destructive, 5-parameter, 4-required mutation with no output schema, the description covers reference breakage but omits the size of the deletion (count/default/max) and what the tool returns. Adequate, but an agent still has to infer how much is deleted.

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

Parameters2/5

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

Schema description coverage is only 20% (just `start`), so the description must compensate and largely does not. It restates `start` and implies the rows/columns axis, but says nothing about `count` (its default of 1, its 100000 cap, or what happens when it is omitted), nor about path/sheet scoping.

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 verb and resource (delete rows or columns), anchored to the `start` parameter, which cleanly distinguishes it from siblings like insert_rows_or_columns and delete_sheet. An agent can identify the operation and the anchor point without opening the schema.

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?

Usage is implied by the name and the cross-reference to insert_rows_or_columns, but there is no explicit when/when-not guidance or named alternative. The reference to the sibling tool hints at the mental model without stating selection criteria.

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