Skip to main content
Glama
SheetForge MCP

SheetForge MCP

by iHeldan

read_data_from_excel

Read-only

Reads data from a specified Excel worksheet, including cell metadata and validation rules, or a plain value grid, so AI agents can inspect spreadsheet ranges without Excel.

Instructions

Read data from Excel worksheet with cell metadata including validation rules.

Args:
    filepath: Path to Excel file
    sheet_name: Worksheet tab name, NOT a native table name; list_tables maps tables to tabs
    start_cell: Starting cell (default A1)
    end_cell: Ending cell (optional, auto-expands if not provided)
    max_rows: Optional maximum number of rows to return from the starting row
    max_cols: Optional maximum number of columns to return from the starting column
    cursor: Optional continuation token returned by an earlier range read
    preview_only: Whether to return preview only
    compact: Whether to omit default validation metadata for smaller responses
    values_only: Whether to return a 2D value grid without per-cell metadata

Returns:  
JSON string containing either structured cell data with validation metadata
or a plain 2D value grid when values_only=True.

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": {
      "filepath": "<filepath>",
      "sheet_name": "<sheet_name>"
    },
    "name": "read_data_from_excel"
  }
}

Input Schema

NameRequiredDescriptionDefault
cursorNo
compactNo
end_cellNo
filepathYesReuse supplied server path; NEVER prepend client cwd. Rooted: relative OK; unrooted stdio: absolute, ask if missing.
max_colsNo
max_rowsNo
sheet_nameYes
start_cellNoA1
values_onlyNo
preview_onlyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.14.0
    • addedInput schema / properties / filepath / description
      Added value: +"Reuse supplied server path; NEVER prepend client cwd. Rooted: relative OK; unrooted stdio: absolute, ask if missing."
  2. First observedv0.8.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, and the description adds real behavioral detail: end_cell auto-expands when omitted, cursor is a continuation token from an earlier range read, compact suppresses default validation metadata, and values_only changes the return shape. It does not discuss size limits or what happens on invalid ranges, keeping it below a 5.

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?

Front-loaded summary sentence followed by a scannable Args list and a Returns note; no padding. The one weak line is the tautological preview_only entry, but overall it is efficiently sized for a 10-parameter tool.

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?

With no output schema, the explicit Returns section covering both the structured cell form and the 2D grid is important and present. What is missing is concrete behavior for preview_only and any pagination/truncation semantics beyond the cursor token.

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 only 10%, so the description must compensate, and it largely does: every one of the 10 params gets an explanatory line, including the non-obvious ones (sheet_name vs table name, end_cell auto-expansion, cursor continuation, compact metadata omission). preview_only is described tautologically ('Whether to return preview only'), leaving one real gap.

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 ('Read data from Excel worksheet') plus the distinguishing payload ('cell metadata including validation rules'). It does not explicitly differentiate from close siblings like read_excel_table, quick_read, or read_excel_as_table, so an agent must infer the boundary.

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 (range reads with metadata, optional values-only mode), and it usefully warns that sheet_name is a tab, not a table, routing to list_tables. However there is no explicit 'use this instead of quick_read/read_excel_as_table when…' guidance despite several overlapping siblings.

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

Deploy Server

Other Tools