Zovo Spreadsheet Merge

Combine spreadsheets

combine_spreadsheets

Read-only

Use this when the user wants to stack or append many spreadsheets into one: "combine multiple csv files into one", "merge 12 monthly excel files", "combine excel files with different column names", "append these exports into one sheet", "combine all sheets into one". Takes 1 to 24 CSV, TSV or .xlsx files (or pasted tables). Aligns columns by identical name, then same name with different case or spacing, then a synonym table (Amt = Amount, Txn Date = Date, Memo = Description), then fuzzy spelling matches that are listed for confirmation; a specific column is not folded into a more general one (Spouse First Name stays separate from First Name). Adds a Source file column, decides day/month order once per file, reads EU number formats, removes total rows and repeated headers (listed), and reports each column decision. Returns an Excel workbook (Combined, Column mapping, Files, Excluded rows, Summary) and a CSV. Does not join files side by side on an ID (use join_spreadsheets) and does not do mail merge.

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

Input Schema

Name	Required	Description
`files`	No	The spreadsheets to stack, 1 to 24 CSV, TSV or .xlsx files in order, e.g. jan.csv, feb.csv, mar.csv. One workbook alone stacks all of its sheets.
`tables`	No	Only when no files are attached: pasted tables to stack, e.g. [{"name":"Jan","csv":"Date,Amt\n1/5/2025,12.50"}].
`all_sheets`	No	Stack every sheet of each workbook instead of only the first sheet with data. Default: true when a single workbook is given, otherwise false.
`column_map`	No	Your column decisions: source header -> output column, e.g. {"Amt":"Amount","Txn Date":"Date"}. Overrides automatic matching.
`date_order`	No	Day/month order for numeric dates: auto (default) decides once per file from the data and says when it had to assume US month/day; MDY or DMY forces it for all files. Example: DMY.
`header_row`	No	Only if the headings were detected wrongly: the header row number used for EVERY file (counting non-blank rows in a CSV, sheet rows in Excel), e.g. 4.
`unify_case`	No	Default true: in short category-style columns, spellings that differ only by case (Revenue vs revenue) become the spelling seen first (first file wins); each change is listed. false keeps values as typed.
`remove_duplicate_rows`	No	Default false: rows identical in every column are counted and reported but kept. true drops the repeats (e.g. overlapping monthly exports).

Output Schema

Name	Required	Description	Default
`note`	Yes
`rows`	Yes
`files`	Yes
`tables`	Yes
`columns`	Yes
`preview`	Yes
`excluded`	Yes
`warnings`	Yes
`downloads`	Yes
`duplicates`	Yes
`not_merged`	Yes
`value_fixes`	Yes
`mapping_changes`	Yes
`needs_confirmation`	Yes
`mapping_changes_total`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 22, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already establish readOnly=true and destructive=false, but the description adds substantial behavior: column alignment precedence, synonym handling, fuzzy-match confirmation, protection against over-generalizing specific columns, source-file columns, per-file date-order decisions, EU number parsing, total-row/header removal, and the workbook tabs returned. No contradiction with the read-only annotation, since transformations are internal rather than mutations of user files.

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?

The description is front-loaded with the use case and then moves into operational details, which is appropriate for a complex 8-parameter tool. It is dense and somewhat run-on, but nearly every clause contributes routing or behavioral information rather than filler.

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?

Given the tool's complexity, nested file/table inputs, and existing output schema, the description supplies enough context to call it correctly: formats, file limits, column-matching strategy, date handling, header detection, duplicate handling, and expected workbook outputs. Nothing essential for correct invocation 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?

Schema coverage is 100%, so the baseline is 3; however, the description adds meaning by explaining the automatic matching hierarchy that column_map overrides and by describing how all_sheets, date_order, unify_case, and remove_duplicate_rows behave in practice. It does not document each parameter individually, but it goes beyond restating the schema.

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 and resource ('stack or append many spreadsheets into one') and anchors it with realistic user phrasings such as 'combine multiple csv files into one' and 'merge 12 monthly excel files'. It explicitly distinguishes itself from join_spreadsheets, so an agent can route correctly without opening either 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?

Opens with an explicit use condition ('Use this when the user wants to stack or append many spreadsheets into one') and gives several trigger examples that match how users actually ask. It also names the exclusion and the alternative: side-by-side ID joins belong to join_spreadsheets, and mail merge is out of scope.

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

All Zovo Spreadsheet Merge tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?