Tools for agents: Collision-safe JSON field renamer

Rename record fields simultaneously with explicit change reports and no silent destination overwrites.

Connect with MCP

{
  "mcpServers": {
    "super-agent-tools": {
      "url": "https://app.getsupers.com/sites/agent-rename-fields/mcp"
    }
  }
}
Streamable HTTP · No API key · Stateless

Use this URL in any client supporting remote Streamable HTTP MCP. Calls return structured JSON; inputs are processed without persistence.

Call rename_record_fields

Mapping keys are source field names and values are destination field names. All names are exact strings, including empty names, and refer only to top-level fields; dots and slashes are literal. Renames are simultaneous: a->b and b->a swaps values, while a->b and b->c moves original a to b and original b to c without cascading. Missing source fields are ignored and mapping sources absent from every record are reported. A destination collision between any two present source fields, including an unchanged field, rejects the entire call. Two sources may map to the same destination only when they never coexist within a record. Identity renames are allowed and do not count as changes. Values, nulls and nested structures are preserved without coercion; nested keys are not renamed. Records and fields retain source order, though JSON consumers need not preserve object order. Empty record lists and mappings are valid. Non-finite numeric values fail. Input is already parsed JSON, so duplicate keys lost during upstream parsing cannot be recovered; use the strict decoder first when needed. No external storage is read or changed.

Input and output schemas
{
  "name": "rename_record_fields",
  "title": "Collision-safe JSON field renamer",
  "description": "Simultaneously rename top-level object keys across records, preserving values and rejecting per-record destination collisions before returning output.",
  "inputSchema": {
    "$defs": {
      "JsonValue": {}
    },
    "properties": {
      "records": {
        "items": {
          "additionalProperties": {
            "$ref": "#/$defs/JsonValue"
          },
          "type": "object"
        },
        "title": "Records",
        "type": "array"
      },
      "mapping": {
        "additionalProperties": {
          "type": "string"
        },
        "title": "Mapping",
        "type": "object"
      }
    },
    "required": [
      "records",
      "mapping"
    ],
    "title": "rename_record_fieldsArguments",
    "type": "object"
  },
  "outputSchema": {
    "additionalProperties": true,
    "title": "rename_record_fieldsDictOutput",
    "type": "object"
  },
  "icons": null,
  "annotations": {
    "title": null,
    "readOnlyHint": true,
    "destructiveHint": false,
    "idempotentHint": true,
    "openWorldHint": false
  },
  "meta": null,
  "execution": null
}

Run the example to see the actual result.

HTTP alternative

POST https://app.getsupers.com/sites/agent-rename-fields/call
Content-Type: application/json

{
  "records": [
    {
      "task_id": "a",
      "status": "ready",
      "result": null
    },
    {
      "task_id": "b",
      "status": "done",
      "result": {
        "count": 2
      }
    }
  ],
  "mapping": {
    "task_id": "id",
    "status": "state",
    "unused": "other"
  }
}

The HTTP and MCP interfaces execute the same implementation. Validation errors are returned explicitly. See the tool notes above for its supported inputs and behavior.

Simultaneous field renaming with collision rejection

Read the explanation

The displayed mapping renames task id to id, status to state, and unused to other. Each of its two records contains the first two source names but not unused. Thus three mappings are declared and two source fields are renamed per record. At seventy pixels per mapping or present source the bars span two hundred ten and one hundred forty. Missing sources are ignored and sources absent from every record are reported. Null result and the nested count object remain unchanged. These are documented transformations, not an actual offline API response; the shared app script is unavailable and no backend request is made. For a hypothetical record with a equal to ten and b equal to twenty, simultaneous mappings a to b and b to a produce b ten and a twenty. Two names change and both values are preserved. At eighty pixels per count both bars span one hundred sixty. Processing mutations sequentially could lose one value, but the documented contract reads original source fields. Similarly a to b and b to c moves original a to b and original b to c without cascading the new b again. Names containing dots or slashes are literal top-level field names rather than nested paths. If two source fields present in one record map to the same destination, the entire call is rejected. At ninety pixels per present source or destination count the bars span one hundred eighty and ninety. An unchanged field can also collide with a renamed destination. Two mappings may share a destination only if their sources never coexist in any record. Identity renames do not count as changes, nested keys are not renamed, and empty record lists or mappings are valid. Because input is already parsed JSON, duplicate keys lost upstream cannot be recovered by this tool. No external storage is read or changed by the documented operation.

Simultaneous Key Remapping and Collision Safety

How does simultaneous field remapping prevent overwrite cascades and collision errors across JSON records?

Procedural loops that rename fields sequentially risk destructive cascades: remapping key A to B and subsequently B to C moves original A data into C. The rename_record_fields tool avoids this by evaluating all top-level keys simultaneously per record. Each record constructs a fresh dictionary mapping target names to values while tracking destination collisions. If two source keys map to the same destination in any single record, or collide with an unmapped key, the entire operation halts and rejects before producing output.

Renaming applies solely to top-level object keys and does not traverse nested dictionaries or arrays. Input must already be valid parsed JSON; duplicate keys dropped by upstream decoders cannot be recovered. Destination collisions are evaluated strictly per record: two distinct sources may map to the identical destination name only if they never appear together in the same object.

Try a worked example

Inspect the default arguments: task_id maps to id and status maps to state, while unused maps to other. When you click Run tool, the status indicator immediately updates to Running… as the asynchronous execution initiates. Once evaluated, task_id and status are simultaneously remapped without altering unmodified nested values like result, and unused is reported under unused_mapping_sources.

Simultaneous Evaluation vs. Sequential Cascades

In a sequential renaming approach, updating a record in place can overwrite existing properties or unintentionally cascade through downstream mappings. The rename_record_fields implementation computes the destination mapping for each existing top-level key against the original record simultaneously, enabling cyclical swaps such as a->b and b->a without intermediate temporary keys.

Per-Record Collision Detection and Audit Output

For each row, the implementation tracks occupied destination names. If an explicitly remapped key or an untouched existing key targets an already claimed destination name in that record, execution raises a ValueError and returns no partial results. When successful, the tool emits a detailed changes list noting exact field transformations per row alongside unused mapping keys.