Skip to main content
Glama

Setup List Mcp Tool

setup_list
Destructive
Map a REACH list's columns to the input fields a job type reads, so `create_job` can run on it.

1. Call without `header_map`; this call changes nothing. When `already_mapped` is true, `header_map` is the list's saved mapping: go to `create_job`. Otherwise `header_map` is REACH's guess, shown with `sample_rows`.
2. Confirm doubtful columns and any unmapped needed field with the user against `sample_rows`, then call again with `header_map` to apply it. The list needs every field of at least one of `required_field_sets`.
3. When `is_valid_for_job_type` is true, call `create_job`, which still checks the list's size, export status and the account's access.

REACH-generated lists keep the mapping their job gave them; only Data Workbench output, lists with a field mapped to several columns, and b2b2c_append accept a new one.

Input Schema

NameRequiredDescriptionDefault
list_idYesList to set up, from `list_lists` or `show_list`
job_typeYesThe `create_job` job_type this list will feed
has_headerNoApplied with `header_map`: whether the file's first row is a header. Defaults to REACH's guess.
header_mapNoInput field name to zero-based column index, e.g. {"first": 0, "email": 3}. Omit to see the guess; pass to apply.

Output Schema

NameRequiredDescriptionDefault
appliedNoTrue when this call saved `header_map` to the list; false for a guess
list_idNo
job_typeNo
has_headerNo
header_mapNoInput field name to zero-based column index: the saved mapping, the guess, or the mapping just applied
sample_rowsNoThe file's first rows, positional, including the header row when there is one
allowed_fieldsNo
already_mappedNoTrue when the list's saved mapping already passes `create_job`'s mapping and data-type checks for job_type; `header_map` is then that mapping
validation_errorsNo
required_field_setsNo
is_valid_for_job_typeNoWhether the list as saved now passes `create_job`'s mapping and data-type checks for job_type

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior4/5

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

Annotations declare destructiveHint=true, and the description adds the crucial nuance that the call without `header_map` changes nothing — a dry-run mode the annotations alone would obscure. It also notes that `create_job` re-validates size, export status, and account access, so this tool isn't the last gate. It stops short of explaining what an applied mapping overwrites on the underlying list.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Opens with a single-sentence purpose, then numbers the workflow steps so the two-phase call pattern is front-loaded. The closing paragraph on which lists accept a new mapping is dense but every sentence informs the call decision.

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?

With an output schema present, the description correctly avoids documenting return values and instead explains how to use the response fields it references. For a stateful, dry-run-then-apply mutation tool, the agent has everything needed to sequence the calls.

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 semantics: `header_map` omission versus passing it defines the preview/apply split, and the response fields `already_mapped`, `sample_rows`, and `is_valid_for_job_type` are given operational meaning. `has_header` is only loosely covered ("applied with header_map").

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 ("Map a REACH list's columns to the input fields a job type reads") plus the downstream purpose (so `create_job` can run). It clearly separates this tool from siblings like `create_job`, `preview_list`, and `show_list` by naming their roles explicitly.

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?

Provides an explicit three-step workflow with a no-op first call, when to consult `sample_rows`, when to apply `header_map`, and when to hand off to `create_job`. It also states exclusions: REACH-generated lists keep their mapping, while only Data Workbench output and b2b2c_append-style lists accept a new one.

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