Skip to main content
Glama

Compare two versions of a table

table_diff
Read-onlyIdempotent

Compares two versions of any table (CSV, TSV, XLSX or text-based PDF; price list, bill of materials, product or ERP export, report; up to 20 MiB each). Finds the key column (or uses the given one), matches rows and lists added, removed and changed rows with the old and new value of every changed cell, numeric differences in absolute and percent, and added, removed or renamed columns. Numbers are compared by value, so 1.234,56 and 1234.56 are equal. Files can be passed as upload, URL or CSV text.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyNoKey column header(s) as in the old file; detected when omitted.
optionsNoOptional DiffOptions, e.g. {"column_map": {"Qty": "Quantity"}, "ignore_columns": ["Updated"], "numeric_tolerance": "0.01", "ignore_case": true}. Schema: /v1/schemas/table-diff-options.
new_fileNoNew version of the table. A file uploaded in ChatGPT (object with download_url and file_id).
old_fileNoOld version of the table. A file uploaded in ChatGPT (object with download_url and file_id).
max_changesNoRow changes returned (counts stay complete).
new_file_urlNoNew version. Public URL of the file (http/https). Google Drive, Google Sheets and Dropbox share links are converted to direct downloads. Max 20 MiB.
new_filenameNoOriginal filename with extension (e.g. prices.xlsx); used to detect the format.
old_file_urlNoOld version. Public URL of the file (http/https). Google Drive, Google Sheets and Dropbox share links are converted to direct downloads. Max 20 MiB.
old_filenameNoOriginal filename with extension (e.g. prices.xlsx); used to detect the format.
new_file_pathNoLocal file path; only allowed when the server runs locally over stdio.
new_file_textNoNew version. The table as CSV or TSV text, header row first (e.g. 'SKU;Price;Currency\nA1;12.50;EUR').
old_file_pathNoLocal file path; only allowed when the server runs locally over stdio.
old_file_textNoOld version. The table as CSV or TSV text, header row first (e.g. 'SKU;Price;Currency\nA1;12.50;EUR').
new_file_base64NoNew version. File content as Base64 (standard alphabet). Max 20 MiB decoded.
old_file_base64NoOld version. File content as Base64 (standard alphabet). Max 20 MiB decoded.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare the safe read-only, idempotent profile, and the description adds substantial extra behavior: 20 MiB per-file limit, key-column auto-detection, row-matching semantics, per-cell old/new reporting with absolute and percent numeric deltas, column add/remove/rename detection, and locale-tolerant number equality. That is exactly the kind of context annotations cannot carry.

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?

Three front-loaded sentences that lead with the action and then layer formats, output, and input modes; nearly every clause carries information. The long semicolon-chained sentence is dense but not padded.

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 a 15-parameter, nested-object tool this is complete: input modes, size limits, key handling, comparison semantics, and output shape are all covered, and an output schema exists so return values need not be spelled out further.

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 100%, so the baseline is 3, but the description adds real meaning: numbers compared by value (1.234,56 == 1234.56), the key column is detected when not supplied, and files may arrive as upload, URL, or CSV text. It stops short of clarifying the priority/conflict rules among the many mutually exclusive input parameters.

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 specific verb (compares) and resource (two versions of a table), then enumerates the accepted formats and file families, making it clearly distinguishable from schema_normalize or merchant_validate. The phrase 'any table' also implicitly positions it as the generic alternative to the narrower supplier_compare sibling.

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

Usage Guidelines4/5

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

Gives clear context for when it applies (any table type, up to 20 MiB, four input modes) and notes that the key column is auto-detected when omitted. It never explicitly names when to prefer a sibling tool such as supplier_compare, so there is context but no exclusions.

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