delete_rows_or_columnsRemove rows or columns from an Excel sheet starting at a specific position. Shifts remaining references, turning links to deleted cells into #REF! errors.
Delete rows or columns from start. References move as in insert_rows_or_columns;
one to a deleted cell becomes #REF!.
| Name | Required | Description | Default |
|---|---|---|---|
| axis | Yes | ||
| path | Yes | ||
| count | No | ||
| sheet | Yes | ||
| start | Yes | 1-based row, or column number (A=1). |
Changes observed during successful MCP inspections.
v2.0.0Input schema / properties / atRemoved value: -{
- "description": "1-based row number, or 1-based column number (A=1).",
- "minimum": 1,
- "title": "At",
- "type": "integer"
-}Input schema / properties / axis / descriptionRemoved value: -"Whether to act on rows or columns."Input schema / properties / axis / titleRemoved value: -"Axis"Input schema / properties / count / descriptionRemoved value: -"How many rows or columns."Input schema / properties / count / minimumRemoved value: -1Input schema / properties / count / titleRemoved value: -"Count"Input schema / properties / path / descriptionRemoved 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."Input schema / properties / path / titleRemoved value: -"Path"Input schema / properties / sheet / descriptionRemoved value: -"Worksheet name, e.g. 'Sheet1'."Input schema / properties / sheet / titleRemoved value: -"Sheet"Input schema / properties / startAdded value: +{
+ "description": "1-based row, or column number (A=1).",
+ "type": "integer"
+}Input schema / requiredPrevious value: -[
- "path",
- "sheet",
- "axis",
- "at"
-]New value: +[
+ "path",
+ "sheet",
+ "axis",
+ "start"
+]Input schema / titleRemoved value: -"delete_rows_or_columnsArguments"Output schema / (root)Previous value: -{
- "properties": {
- "result": {
- "title": "Result",
- "type": "string"
- }
- },
- "required": [
- "result"
- ],
- "title": "delete_rows_or_columnsOutput",
- "type": "object"
-}New value: +nullv1.1.1Does 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.
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.
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.
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.
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.
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.