SheetForge MCP

Overview Schema Source Related Servers Discussions Admin

cross_workbook_lookup

Read-only

Enrich one workbook dataset by joining matching rows from one or more lookup workbooks, enabling cross-file data consolidation without manual lookups.

Instructions

Enrich one workbook dataset from matching rows in one or more lookup workbooks.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "source_filepath": "<source_filepath>",
      "lookup_filepaths": "<lookup_filepaths>",
      "source_key": "<source_key>"
    },
    "name": "cross_workbook_lookup"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No
`select`	No
`row_mode`	No		arrays
`join_type`	No		left
`lookup_key`	No
`match_mode`	No		first
`source_key`	Yes
`schema_mode`	No		strict
`infer_schema`	No
`lookup_select`	No
`case_sensitive`	No
`lookup_sort_by`	No
`source_filepath`	Yes	Reuse supplied server path; NEVER prepend client cwd. Rooted: relative OK; unrooted stdio: absolute, ask if missing.
`lookup_filepaths`	Yes
`lookup_sort_desc`	No
`lookup_header_row`	No
`lookup_sheet_name`	No
`lookup_table_name`	No
`source_header_row`	No
`source_sheet_name`	No
`source_table_name`	No
`lookup_sample_limit`	No
`include_lookup_match_count`	No
`include_lookup_source_columns`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.14.0Oct 31, 2026

addedInput schema / properties / lookup_filepaths / items / description

Added value: +"Reuse supplied server path; NEVER prepend client cwd. Rooted: relative OK; unrooted stdio: absolute, ask if missing."

addedInput schema / properties / source_filepath / description

Added value: +"Reuse supplied server path; NEVER prepend client cwd. Rooted: relative OK; unrooted stdio: absolute, ask if missing."

First observedv0.8.0Aug 7, 2026

TDQS

C2.7/5.0

Behavior2/5

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

The readOnlyHint annotation only confirms this is a non-mutating read, so the description carries the rest of the burden and discloses almost nothing. With 24 parameters controlling join_type, match_mode, schema_mode, and row_mode -- all of which materially change behavior -- plus no output schema, the description gives no insight into what happens with multiple lookup workbooks, duplicate matches, or schema mismatches.

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?

A single front-loaded sentence with no padding and the core operation stated first. It is efficient, though the extreme brevity for a 24-parameter tool suggests under-specification rather than genuine editorial discipline.

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

Completeness2/5

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

Given 24 parameters, 4% schema coverage, no output schema, and only a readOnlyHint annotation, the definition leaves far too much unspecified. An agent cannot determine what the enriched result looks like, how multiple lookups compose, or how the mode parameters interact.

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

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 4%: only source_filepath and lookup_filepaths items carry descriptions, leaving roughly 22 parameters documented by title alone. The phrase 'one or more lookup workbooks' faintly echoes that lookup_filepaths is a list, but the description adds nothing about join_type, match_mode, or the select/limit parameters.

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?

The description pairs the specific verb 'Enrich' with the resource 'workbook dataset' and clarifies that the enrichment comes from matching rows in lookup workbooks, so it reads as a join/lookup operation. It is distinguishable from siblings such as union_tables or aggregate_table, though it never names an alternative explicitly.

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

Usage Guidelines2/5

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

There is no statement of when to use this instead of union_tables, query_table, or bulk_filter_workbooks, and no prerequisites or exclusions. The agent must infer the tool's role from the name and description alone.

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

Deploy Server