Skip to main content
Glama

Derive a column

derive_column

PAID (needs a key) — AI tokens by use (usually cents; at most 10 credits per call, within the key's day budget): fill an existing column from others by an instruction (e.g. the gender from the first name, a seniority from the job title, a country from the city). Unique values are asked once.

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>",
      "source_columns": "<source_columns>",
      "target_column": "<target_column>",
      "description": "<description>"
    },
    "name": "derive_column"
  }
}

Input Schema

NameRequiredDescriptionDefault
filterNoColumn → value: exact, { "contains": "…" }, { "not": "…" }, { "is_empty": true } or { "condition": "<one of filter_conditions>" }; ar_status by status name
list_idYesThe list's id (describe_list without list_id shows the lists shared with you)
languageNoLanguage of `tell_your_user` (default en)
only_emptyNoFill empty cells only (default true)
descriptionYesWhat to put in, e.g. "male, female or unknown from the first name"
target_columnYesThe (existing) column to fill
source_columnsYesThe columns to read

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.6/5.0
Behavior4/5

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

The description adds substantial context beyond the annotations: it is a paid AI operation requiring a key, costs at most 10 credits per call against a daily key budget, and deduplicates work because unique values are asked only once. That pricing/auth/dedup disclosure is exactly what annotations (readOnlyHint false, destructiveHint false, openWorldHint true) cannot convey. It stops short of saying whether this runs synchronously or as a job, or what happens to non-empty cells beyond the schema's only_empty default.

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 cost and key requirement are front-loaded before the purpose, and the examples are compact. The em-dash-and-parenthesis chain is dense and takes a moment to parse, but no sentence is wasted.

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

Completeness3/5

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

For a 7-parameter mutation with a nested filter object and no output schema, the description covers purpose, cost and deduplication but omits return behavior (does it return counts, a job id, or nothing), failure modes, and whether the operation is reversible. It is adequate to call the tool, but not fully complete for its complexity.

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 description coverage is 100%, so every parameter including the nested filter object is already documented. The description's instruction examples mirror the example already in the description parameter's schema entry, adding minimal new meaning. Baseline 3 is appropriate when the schema carries the parameter burden.

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: fill an existing column from other columns by an instruction, backed by three concrete examples (gender from first name, seniority from job title, country from city). The word 'existing' implicitly separates it from the sibling add_column, but no sibling is named explicitly.

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

Usage Guidelines3/5

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

The agent can infer when to use it (deriving values into a column that already exists) and the cost gate makes the tradeoff visible. There is no explicit when-not guidance, no named alternative to add_column or enrich_records, and no statement about what to do when the target column does not exist.

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