Skip to main content
Glama
eschaq

Excel MCP Server

by eschaq

write_range

DestructiveIdempotent

Write a 2D block of values into an Excel spreadsheet starting at a specified cell, enabling batch updates across multiple rows and columns in one operation.

Instructions

Write a 2D block of values (rows of cells) starting at a cell in an .xlsx/.xlsm file.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesPath to the spreadsheet file (absolute, or relative to the first allowed directory)
sheetNoSheet name. Defaults to the first sheet.
valuesYes2D array of rows to write
start_cellYesTop-left cell of the block, e.g. 'A2'

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=true, readOnlyHint=false, so the mutation profile is covered by structured data. The description contributes the file-format constraint (.xlsx/.xlsm), but does not disclose the key behavior an agent would want: that existing cell contents in the target rectangle are overwritten, or how formatting is handled.

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?

A single sentence, front-loaded with the action and resource, with no filler. It is efficient, though it is arguably too terse for a destructive block write and leaves room for one more useful clause.

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 4-parameter destructive write with no output schema, the description is adequate but thin: it omits overwrite semantics, sheet-existence requirements, and whether ranges may extend the used region. Annotations cover the safety signal, which keeps this at minimum-viable rather than deficient.

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 100%, so path, sheet, values and start_cell are all documented in the schema. The description echoes the shape ('2D block', 'starting at a cell') but adds no format details, value-coercion rules, or behavior beyond what the schema already provides; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (Write) and resource (a 2D block of values / rows of cells) with the origin point (starting at a cell) and file scope (.xlsx/.xlsm). The '2D block' framing implicitly separates it from the single-cell sibling write_cell, but it never names that sibling to make the distinction explicit.

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 description ('starting at a cell in an .xlsx/.xlsm file'), which tells the agent the tool applies to block writes in supported formats. There is no explicit when-to-use versus write_cell, and no exclusions or prerequisites (e.g. sheet must exist, whether existing data is overwritten).

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