Skip to main content
Glama

Join two spreadsheets

join_spreadsheets
Read-only

Use this when the user wants to merge, match or VLOOKUP two spreadsheets on a shared ID column: "vlookup two spreadsheets", "merge two excel files by customer ID", "match orders to customers", "why are some rows not matching", "find which IDs are missing from the other file". Attach both files (CSV, TSV or .xlsx; or one workbook with two sheets) or paste both tables. Left join by default (all left rows kept); inner and full joins are available. Auto-detects the key column and explains why (override with left_key/right_key, or give a composite key). Key clean-ups are applied in order and each is counted: spaces, case, look-alike characters, Excel number formats (12345.0, 1.2345E+05), separators, leading zeros (C00123 = C123), letter prefix used by one file only; turn any off with skip_normalizations. Reports unmatched rows on both sides with a likely reason and closest key, duplicate keys with fan-out counts, and returns an Excel workbook (Merged, Unmatched left, Unmatched right, Duplicates, Summary) plus a merged CSV. Does not do mail merge (letters, labels, emails), does not compare two versions of one file cell by cell, and does not edit the original files.

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

Input Schema

NameRequiredDescriptionDefault
left_keyNoKey column name(s) in the left file; leave out to auto-detect. Use a list for a composite key, e.g. "customer_id" or ["First Name","Last Name"].
join_typeNoleft (default, like VLOOKUP): keep every left row and add matching right columns. inner: only rows found in both. full: everything from both files, matched where possible. Example: left.
left_fileNoThe main file whose rows you keep (CSV, TSV or .xlsx), e.g. orders.csv. A workbook with two sheets can be passed alone: sheet 1 is joined to sheet 2.
right_keyNoKey column name(s) in the right file; leave out to auto-detect. Use a list for a composite key, e.g. "Customer ID" or ["First Name","Last Name"].
duplicatesNoWhen a key appears more than once in the right file: all (default) keeps every match and warns about the extra rows; first keeps only the first match, like VLOOKUP. Example: first.
left_sheetNoSheet name in the left workbook, e.g. Orders. Default: the first sheet with data.
left_tableNoOnly when no file is attached: the left (main) table pasted as CSV or tab-separated text with a header row, e.g. "order_id,customer_id,amount\nSO-1,C123,40.00".
right_fileNoThe lookup file whose columns are added (CSV, TSV or .xlsx), e.g. customers.xlsx.
right_sheetNoSheet name in the right workbook, e.g. Customers. Default: the first sheet with data (or the second sheet when both tables are in one workbook).
right_tableNoOnly when no file is attached: the right (lookup) table pasted as CSV or tab-separated text with a header row, e.g. "customer_id,name\nC00123,Acme Supply".
left_header_rowNoOnly if the headings were detected wrongly: the row number of the left file's header (counting non-blank rows in a CSV, sheet rows in Excel), e.g. 4.
right_header_rowNoOnly if the headings were detected wrongly: the row number of the right file's header, e.g. 3.
skip_normalizationsNoKey clean-ups to turn OFF when IDs that differ only that way are really different, e.g. ["case"] for case-sensitive IDs or ["zeros"] when 0123 and 123 are different codes. Options: trim, case, unicode, excel, separators, zeros, prefix.

Output Schema

NameRequiredDescriptionDefault
leftYes
noteYes
matchYes
rightYes
excludedYes
warningsYes
downloadsYes
join_typeYes
duplicatesYes
key_choiceYes
turned_offYes
prefix_ruleYes
normalizationsYes
unmatched_previewYes
unmatched_reasonsYes
would_match_if_onYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real value beyond that: the ordered normalization pipeline, the auto-detect-with-explanation behavior, duplicate fan-out handling, and the exact output artifacts (five-sheet workbook plus merged CSV). It stops short of stating size limits, runtime, or what happens on total key-detection failure, so it is good but not exhaustive for a heavy multi-step operation.

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 trigger condition and examples before mechanics, and every sentence carries operational content. It is dense and long, and a few clauses (file format list, repeated key examples) duplicate schema details, keeping it from a 5.

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 13-parameter, nested-object tool, the description covers inputs (attach vs. paste, single-workbook mode), join semantics, duplicate handling, and exclusions. An output schema exists, yet the description still names the returned sheets, which is more than sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/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. The description reinforces the important semantics — left_key/right_key override auto-detection, composite keys, skip_normalizations turning off individual clean-ups — but mostly restates what the schema already documents per parameter.

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 ('merge, match or VLOOKUP two spreadsheets on a shared ID column') and enumerates the exact user phrasings that select it. The join-on-a-key framing implicitly separates it from a stacking/combine operation, but the sibling tool combine_spreadsheets is never named, 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 Guidelines5/5

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

Gives concrete trigger utterances ('merge two excel files by customer ID', 'why are some rows not matching'), states the default behavior (left join), and lists what it explicitly will not do (mail merge, cell-by-cell version compare, editing originals). The agent knows both when to pick this and when to look elsewhere.

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