Skip to main content
Glama

Compare spreadsheets

compare_spreadsheets
Read-only

Use this when the user has two versions of the same spreadsheet (CSV or Excel: price list, inventory, roster, budget, product catalog, CRM export) and wants to "compare two excel files", "compare two spreadsheets", "find the differences between two csv files", "what changed between these files" or "list what changed". Matches rows by a key column it detects (or key_columns), lists all added, removed and changed rows with each changed cell old -> new, numeric change and percent, plus renamed/moved columns and key changes, and returns an Excel workbook (Summary, Changed, Cell changes, Added, Removed, annotated new version) and a changes CSV. Does not merge or join two different tables (e.g. customers + orders), does not compare Word or PDF documents, and does not edit either file.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "compare_spreadsheets"
  }
}

Input Schema

NameRequiredDescriptionDefault
new_fileNoThe NEWER version (CSV, TSV or Excel .xlsx), e.g. pricelist_2026Q4.xlsx or roster-october.csv.
old_fileNoThe OLDER version (CSV, TSV or Excel .xlsx), e.g. pricelist_2026Q3.xlsx or roster-september.csv.
new_sheetNoSheet (tab) to read from the new workbook, e.g. Prices Q4.
new_tableNoInstead of new_file: the newer version pasted as CSV/TSV text with a header row, e.g. "SKU,Price\nA1,10.50\nC3,7.00".
old_sheetNoSheet (tab) to read from the old workbook, e.g. Prices Q3. Default: the sheet with the same name as in the new workbook, else the first sheet with data.
old_tableNoInstead of old_file: the older version pasted as CSV/TSV text with a header row, e.g. "SKU,Price\nA1,10.00\nB2,5.00".
column_mapNoOld column name -> new column name for renamed columns, e.g. {"Unit Price": "Price (USD)"}. Turns off automatic rename detection.
ignore_caseNoTreat ABC and abc as equal, e.g. true. Default false.
key_columnsNoColumn(s) that identify a row, to override the automatic key, e.g. ["SKU"] or ["Store", "Product code"].
header_row_newNoRow number of the column headings in the new file, e.g. 3.
header_row_oldNoRow number of the column headings in the old file when it is not detected, e.g. 3 when two title rows come first.
ignore_columnsNoColumns to leave out of the comparison, e.g. ["Last updated", "Notes"].
normalize_datesNoCompare dates by calendar day, so 2026-03-05, 3/5/2026 and an Excel date serial are equal, e.g. true (default).
trim_whitespaceNoIgnore leading/trailing and repeated spaces, e.g. true (default).
numeric_toleranceNoNumbers that differ by this much or less count as equal, e.g. 0.01 to ignore rounding by a cent. Default 0.
detect_key_changesNoReport a removed row and an added row whose other values are identical as one key change (e.g. a SKU renumbered), e.g. true (default).
compare_row_numbersNoCompare a running row-number column (#, Row, No.: 1, 2, 3...) like any other column, e.g. true. Default false: it shifts whenever a row is inserted, so it is skipped with a note.
compare_numbers_as_valuesNoCompare numbers by value so "1,200.00" equals 1200, e.g. true (default). Codes with leading zeros (00123) stay text.

Output Schema

NameRequiredDescriptionDefault
keyYes
filesYes
notesYes
countsYes
columnsYes
by_columnYes
downloadsYes
added_previewYes
complete_listYes
excluded_rowsYes
biggest_changesYes
changes_previewYes
removed_previewYes
key_changes_previewYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Goes well beyond the readOnly/destructive annotations by disclosing the matching mechanism (a detected key column or key_columns), rename/key-change detection, and the exact deliverables (six-sheet workbook plus a changes CSV). The 'does not edit either file' clause only restates destructiveHint=false, and no failure mode (e.g. no key column found) is described.

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 with the use case, then output, then exclusions — the right order for an agent. It is dense and the long run of quoted trigger phrases plus sheet-by-sheet output enumeration is slightly over-packed for a single paragraph.

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

Completeness5/5

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

For an 18-parameter tool with nested file objects and an output schema, the description covers scope, exclusions, matching behavior, and returned artifacts. Defaults and per-parameter details are fully carried by the schema, so nothing an agent needs to invoke it is missing.

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?

With 100% schema coverage the baseline is 3, but the description adds cross-parameter context the schema cannot: that a key is auto-detected and key_columns overrides it, and that renamed/moved columns are detected automatically. It does not mention the file-vs-pasted-table duality that drives new_file/new_table.

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 precise verb+resource ('compare spreadsheets') and backs it with concrete carriers (price list, inventory, roster, budget) and output artifacts. The negative scoping ('does not merge or join two different tables', 'does not compare Word or PDF') plus the row-level detail implicitly separates it from the summarize_changes sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It opens with an explicit trigger condition ('when the user has two versions of the same spreadsheet'), lists the natural-language phrasings that should select it, and states three concrete when-not cases (dissimilar tables, Word/PDF, editing). Only gap is that it never names summarize_changes as the alternative.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources