Use this URL in any client supporting remote Streamable HTTP MCP. Calls return structured JSON; inputs are processed without persistence.
Call merge_json
Object members merge recursively. Unchanged sides defer to changed sides, and identical changes are accepted. Arrays are atomic: different edits on both sides conflict instead of guessing element identity. Conflicts use JSON Pointer paths and explicit presence flags, so deleted fields differ from null. With conflicts, merged is null and preview retains base values at conflict paths; newly added conflicting fields are omitted. A conflict-free result may itself be null: check clean, not merged truthiness. No files are modified, no shared state is stored, and no agent claims are acquired.
Input and output schemas
{
"name": "merge_json",
"title": "Three-way JSON merge",
"description": "Merge independent object edits against a common base. Conflicts retain the base in preview and return each side with presence flags. Arrays are atomic. Never writes external state.",
"inputSchema": {
"$defs": {
"JsonValue": {}
},
"properties": {
"base": {
"$ref": "#/$defs/JsonValue"
},
"left": {
"$ref": "#/$defs/JsonValue"
},
"right": {
"$ref": "#/$defs/JsonValue"
}
},
"required": [
"base",
"left",
"right"
],
"title": "merge_jsonArguments",
"type": "object"
},
"outputSchema": {
"additionalProperties": true,
"title": "merge_jsonDictOutput",
"type": "object"
},
"icons": null,
"annotations": {
"title": null,
"readOnlyHint": true,
"destructiveHint": false,
"idempotentHint": true,
"openWorldHint": false
},
"meta": null,
"execution": null
}
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.
Three-way JSON merge: unchanged sides, conflicts and presence
Read the explanation
The saved three-way JSON merge example begins with task status draft and owner agent a. The left changes status to ready, while the right changes it to blocked. Both differ from the common base and from each other, so the documented contract reports a conflict at JSON Pointer slash task slash status. The animated branches show two incompatible edits converging; the preview retains the base status draft instead of silently picking a winner. With any conflict, clean is false and merged is null. The preview remains useful for reviewing nonconflicting paths, but it is not an approved merged result. The diagram derives this behavior from the visible input and documentation. This local run does not execute the HTTP or MCP service, acquire agent ownership, modify files or write shared state. For the owner field, the left equals the base agent a and the right changes it to agent b. The unchanged side defers to the changed side, so this path resolves to agent b. Separately, the left adds checks with lint true, while the right has no checks field and the base also has none. That uncontested addition is retained. Both sides leave the labels array as review, so it remains unchanged. Objects merge recursively, allowing distinct fields to resolve independently. The status conflict from the previous scene still means the entire example is not clean and its final merged field is null. Only its preview contains these resolved fields plus draft at the conflicting status. Resolving one branch therefore does not erase a conflict elsewhere. These rules describe the documented merge semantics, not a tested service response. A deletion and an explicit JSON null are different edits because conflict records include presence flags. In an illustrative base with x equal one, the left deletes x and the right sets x to null. Both differ from the base, so this conflicts; the preview retains one. A newly added field with differing left and right values has no base value to retain and is omitted from preview at that conflict path. Arrays are treated as atomic values: different edits on both sides conflict rather than guessing element identity or combining indices. Identical changes are accepted. A conflict-free result may itself be null, for example when the selected clean value is null, so callers must check clean rather than the truthiness of merged. The copied browser form depends on a shared application script absent offline. The explainer teaches these exact input-contract distinctions without claiming backend validation or public structured-output evidence.
Three-way JSON Merge Semantics and Conflict Protocol
How does the three-way JSON merge algorithm reconcile simultaneous edits, evaluate atomic arrays, and represent structural conflicts?
This tool implements a conservative three-way JSON merge across a shared base document and two independent revisions (left and right). When both revisions leave an element unchanged or introduce identical changes, the modification is accepted cleanly. When independent edits touch different object keys, members merge recursively without collision. However, if both sides make divergent changes to the same scalar key, array, or object structure, the tool declines to arbitrarily pick a winner. In conflict states, the algorithm sets clean to false, leaves merged as null, and supplies a preview containing base values alongside structured conflict descriptors using RFC 6901 JSON Pointers.
Arrays are treated strictly as atomic units rather than diffed element-by-element; any independent simultaneous modification to an array triggers a conflict at that path. Furthermore, a conflict-free merge result can itself evaluate to null; downstream callers must inspect the boolean 'clean' flag rather than checking truthiness on 'merged'.
Try a worked example
Submit the preloaded sample JSON containing a common base task, an uncontested owner update by right ('agent-b'), an added checks key by left, and conflicting status updates ('ready' vs 'blocked'). Clicking 'Run tool' executes the merge: 'task.owner' cleanly updates to 'agent-b' and 'checks' is added, while the status divergence produces exactly 1 conflict ('conflict_count': 1). In the structured output, 'clean' is false, 'merged' is null, 'preview.task.status' retains the base value 'draft', and the conflict item records path '/task/status' with base, left, and right values.
RFC 6901 JSON Pointer Path Encoding
Every detected collision is mapped to an RFC 6901 JSON Pointer path. Standard JSON Pointer syntax prefixes each reference token with a forward slash and escapes literal tilde and slash characters as '~0' and '~1' respectively, allowing unambiguous reference to nested keys even when property names contain punctuation. RFC 6901: JavaScript Object Notation (JSON) Pointer
Presence Flags and Base Preservation
The merge implementation distinguishes deleted properties from properties explicitly set to null by recording boolean presence flags (base_present, left_present, and right_present). In conflict mode, preview retains the baseline value for contested paths and omits conflicting novel keys, preventing silent overwrites while downstream agents resolve discrepancies.