graph-excel-mcp

append_rows

Append rows below the last used row in an Excel sheet, starting at a chosen column, with empty-cell checks and read-back verification.

Instructions

Append rows below the last used row of a sheet, starting at column (default A). values is a 2D array, one array per row. Base check: the target cells must still be empty; read back and verified like write_values.

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": {
      "file": "<file>",
      "sheet": "<sheet>",
      "values": "<values>"
    },
    "name": "append_rows"
  }
}

Input Schema

Name	Required	Description
`file`	Yes	Workbook: SharePoint URL, an alias from ~/.graph-excel/workbooks.json, or "driveId:itemId"
`send`	No	false (default) = dry run: shows what would change. true = write — only after the user approved (or a standing rule allows it)
`sheet`	Yes	Worksheet name exactly as listed by resolve
`column`	No
`values`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.5.0Nov 6, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the description's job is to add context — which it does by disclosing the 'base check' that target cells must still be empty, the read-back verification step, and that behavior mirrors write_values. It does not mention failure behavior when the emptiness check fails, so it stops short of full 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?

Three compact sentences: the operation and placement first, then the data shape, then the safety check. No filler, no restatement of the name, and the most load-bearing constraint is front-loaded.

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 5-parameter mutation tool with no output schema, the description covers placement semantics, input shape, and the key safety precondition, with annotations carrying the risk profile. The only material gap is what happens if the emptiness check fails (hard error vs. skip), which an agent would want before invoking.

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

Parameters4/5

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

Schema coverage is 60%: file and send are well documented in the schema, while column and values carry no schema description. The description fills exactly those gaps — column is the starting column with default A, and values is a 2D array with one inner array per row — which is meaningful added meaning rather than repetition.

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 and resource plus a precise placement rule: 'Append rows below the last used row of a sheet, starting at `column` (default A).' That placement rule implicitly separates it from write_values and insert_rows, but no sibling is named, so an agent must infer the boundary from prior knowledge of the toolset.

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 append-past-last-row semantics and the stated precondition that target cells must still be empty, which rules out overwrites. However, it never explicitly says when to prefer this over append_update or write_values, and it does not restate the dry-run/approval gating that governs when the tool actually writes.

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

Deploy Server