Skip to main content
Glama

Check spreadsheet for errors

check_spreadsheet
Read-only

Use this when the user wants to check a spreadsheet for errors or validate data before importing or sending it: "check spreadsheet for errors", "data validation excel", "find duplicates in excel", "check this csv for errors", "find invalid dates", "are there bad emails in this list". Attach a CSV, TSV or .xlsx file or paste the table. With no rules it detects column types from the values and checks impossible, ambiguous and mixed-format dates, invalid emails and email typos, phone digit counts, duplicate IDs and duplicate rows, blank cells in mostly filled columns, text in number columns, numbers stored as text, mixed decimal marks, leading/trailing spaces, IDs that lost leading zeros or became 1.2E+15, formula errors and row totals that do not add up. Optional rules: required_columns, unique_columns, allowed_values, ranges, total_rules. Returns each issue with row, column and cell value, counts per check, a column health score, an Excel copy with problem cells highlighted plus an Issues sheet, and an issues CSV. Does not edit or clean the data, does not verify that mailboxes or phone lines exist, and does not compare two files (use a comparison tool for that).

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": "check_spreadsheet"
  }
}

Input Schema

NameRequiredDescriptionDefault
fileNoThe spreadsheet to check: CSV, TSV or Excel .xlsx, e.g. customers.xlsx.
sheetNoSheet name or number in an Excel workbook, e.g. Orders or 2. Default: the first sheet with data.
tableNoOnly when no file is attached: the table pasted as CSV, tab-separated or a Markdown table with its header row, e.g. "id,date,email\n1,2026-02-30,ana@example.com". A list of rows also works.
rangesNoNumeric limits per column, e.g. {"Age":"0-120","Discount":{"min":0,"max":50}} or "Age: 0-120; Qty: >= 1".
date_orderNoDay/month order for dates like 03/04/2026: auto (default), MDY (US, month first) or DMY (day first).
header_rowNoOnly if the headings were detected wrongly: the row number of the header, e.g. 3.
skip_checksNoChecks to turn off, e.g. ["extra_spaces"]. Options: impossible_date, mixed_date_order, ambiguous_date, mixed_date_format, implausible_date, not_a_date, invalid_email, email_typo, invalid_phone, duplicate_id, duplicate_row, blank_required, not_a_number, number_as_text, mixed_decimal, extra_spaces, lost_leading_zeros, scientific_notation, total_mismatch, formula_error, inconsistent_spelling, extra_cell, impossible_time, not_allowed, out_of_range.
total_rulesNoTotals that must add up, e.g. "Total = Q1 + Q2 + Q3 + Q4" or "Amount = Qty * Price". Default: total columns are detected and checked automatically.
allowed_valuesNoAllowed values per column, e.g. {"Status":["Open","Closed"]} or "Status: Open, Closed; Region: North, South".
unique_columnsNoColumns whose values must not repeat, e.g. "Order ID". Default: the ID column is detected from its header and values.
required_columnsNoColumns that must never be blank, e.g. ["Email","Order ID"] or "Email, Order ID". Default: columns that are almost fully filled are treated as required (blanks reported as warnings).

Output Schema

NameRequiredDescriptionDefault
copyYes
fileYes
kindYes
notesYes
checksYes
columnsYes
summaryYes
downloadsYes
rules_appliedYes
issues_previewYes
totals_checkedYes

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the bar is lower, yet the description adds real context: it explicitly states it does not edit or clean the data, does not verify mailboxes or phone lines exist, and it spells out the returned artifacts (highlighted Excel copy, Issues sheet, issues CSV). It stops short of describing pagination or size limits for very large sheets, which is the only notable gap.

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?

It is front-loaded with the selection triggers, then the input modes, then the check catalogue, then the return values, then the exclusions — a sensible order. The long enumeration of check types is dense but each item carries information; a bulleted or grouped layout would have made it easier to scan.

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 11-parameter, nested-object tool with an output schema and full annotation coverage, the description supplies everything needed to call it correctly: input modes, default behavior, optional rule parameters, output artifacts, and explicit scope limits.

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 schema already documents all 11 parameters; the description nevertheless adds decision-relevant semantics by framing five of them as 'optional rules' and stating the important default that with no rules the tool infers column types and applies its built-in check set. It does not add guidance for date_order, header_row or skip_checks beyond what the schema says.

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?

The description opens with a specific verb+resource ('check a spreadsheet for errors or validate data') and then enumerates exactly which defects it detects (impossible dates, invalid emails, duplicate IDs, numbers stored as text, formula errors). An agent can distinguish this from list_spreadsheet_columns and from a comparison tool without opening any schema.

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 gives explicit trigger utterances ('check this csv for errors', 'find duplicates in excel'), a fallback path when no file is attached ('paste the table'), and named exclusions with routing ('does not compare two files (use a comparison tool for that)'). When-to-use and when-not-to-use are both stated.

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