ListPlus

Fix a list

fix_list

FREE (key) — apply ONE of: a check's proposed fixes (check_id from check_list), cleaning values (trim, casing, placeholders — clean_values: true), or merging duplicates (dedup_key: email, name_company, linkedin, phone, name — merged rows are hidden, not deleted). Needs editing on the list.

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": {
      "list_id": "<list_id>"
    },
    "name": "fix_list"
  }
}

Input Schema

Name	Required	Description
`columns`	No	clean_values: only these columns
`list_id`	Yes	The list's id (describe_list without list_id shows the lists shared with you)
`check_id`	No	A check's id from check_list
`language`	No	Language of `tell_your_user` (default en)
`dedup_key`	No	Merge duplicates found by this key
`record_ids`	No	The records' ids (`id` in query_records)
`clean_values`	No	true = clean values of the given columns / all

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false and destructiveHint=false, but the description adds genuinely new behavioral context: merging is a soft operation ('merged rows are hidden, not deleted'), the tool is quota-metered ('FREE (key)'), and it requires edit permission on the list. It does not disclose whether cleaning/dedup is reversible or what the response contains.

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 cost/quota marker and the 'apply ONE of' framing, then three compact parenthetical mode summaries. There is essentially no filler, though the single dense run-on with nested em-dashes and parentheses is harder to scan than a short bulleted structure would be.

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

Completeness4/5

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

For a 7-parameter, three-mode, no-output-schema mutation tool this covers the essential decision information: which mode, which keys, and that dedup is non-destructive. Gaps remain around record_ids scoping, idempotency/repeat behavior, and the result of the operation, but the core is present.

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 baseline is 3, but the description adds value the schema cannot: it groups parameters into the three mutually exclusive modes (check_id vs clean_values+columns vs dedup_key), which prevents invalid parameter combinations. It does not explain when the optional record_ids scoping applies.

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?

Names a specific verb (fix/apply fixes) and resource (a list), then enumerates the three distinct modes of operation: applying a check's proposed fixes, cleaning values, and merging duplicates. This distinguishes it from siblings like check_list (which proposes) and update_records (which edits arbitrary fields).

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

Usage Guidelines4/5

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

The phrase 'apply ONE of' explicitly states mutual exclusivity, and it routes the agent to check_list as the source of check_id and to describe_list/query_records implicitly for ids. It omits explicit when-not guidance and doesn't say what to do if multiple fixes are needed (run repeatedly?), leaving a small inference gap.

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

All ListPlus 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?