Entity Enricher

Merge records

merge_records

Destructive

Fuse two or more records of the same entity into a new arbitration record. Without arbitration_model use voting, median and union rules; with an arbiter, conflicts may incur LLM cost. Returns output, conflicts, fusion metadata and a new record ID. The merged result can feed linked databases and overwrite current entity values. Inspect database warnings and the actual fusion method; an arbiter failure can fall back to rules. Use this after separately recovered model runs, not to merge different entities. See enricher://docs/enrichment-and-fusion. With arbitration_model='auto' YOU arbitrate (unless use_platform_models=true): the call returns the job status at its first pending request (answer_llm_request) or at the terminal state. A rule-based merge (no arbitration_model) makes no model call and blocks until done.

Input Schema

Name	Required	Description
`result_ids`	Yes	UUIDs of the enrichment records to merge (minimum 2).
`wait_seconds`	No	Delegated merges only: how long to wait for the first pending request or completion before returning.
`attachment_ids`	No	Attachments passed to the arbitration LLM (ignored for rule-based merges).
`arbitration_model`	No	LLM arbitration: None = rule-based (no model call), 'auto' = YOUR model (or the platform's pick with use_platform_models=true), a platform key = that model.
`use_platform_models`	No	false (default): every LLM call of this job runs on YOUR model — the job parks each call as a pending request you answer with answer_llm_request; no credits are consumed. true: the job runs on the platform (billed) and, with the model left on auto, on the organization's best model for the task — its highest blended benchmark score under the organization's quality/speed/cost weights, among the models that satisfy the run (attachments, web search, thinking). Naming a platform model also runs the job there, bypassing that pick: do it only when the user named one. Protocol: enricher://docs/llm-delegation.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 27, 2026

changedInput schema / properties / arbitration_model / description

Previous value: -"Model composite key for LLM arbitration (None = rule-based)."New value: +"LLM arbitration: None = rule-based (no model call), 'auto' = YOUR model (or the platform's pick with use_platform_models=true), a platform key = that model."

removedInput schema / properties / delegate_llm_calls

Removed value: -{
-  "default": false,
-  "description": "Run the arbitration on YOUR model: pass arbitration_model='auto' and answer the pending requests with answer_llm_request; no credits are consumed. Plan feature. Protocol: enricher://docs/llm-delegation.",
-  "title": "Delegate Llm Calls",
-  "type": "boolean"
-}

addedInput schema / properties / use_platform_models

Added value: +{
+  "default": false,
+  "description": "false (default): every LLM call of this job runs on YOUR model — the job parks each call as a pending request you answer with answer_llm_request; no credits are consumed. true: the job runs on the platform (billed) and, with the model left on auto, on the organization's best model for the task — its highest blended benchmark score under the organization's quality/speed/cost weights, among the models that satisfy the run (attachments, web search, thinking). Naming a platform model also runs the job there, bypassing that pick: do it only when the user named one. Protocol: enricher://docs/llm-delegation.",
+  "title": "Use Platform Models",
+  "type": "boolean"
+}

Changed2 schema fields changedOct 22, 2026

addedInput schema / properties / delegate_llm_calls

Added value: +{
+  "default": false,
+  "description": "Run the arbitration on YOUR model: pass arbitration_model='auto' and answer the pending requests with answer_llm_request; no credits are consumed. Plan feature. Protocol: enricher://docs/llm-delegation.",
+  "title": "Delegate Llm Calls",
+  "type": "boolean"
+}

addedInput schema / properties / wait_seconds

Added value: +{
+  "default": 120,
+  "description": "Delegated merges only: how long to wait for the first pending request or completion before returning.",
+  "maximum": 600,
+  "minimum": 0,
+  "title": "Wait Seconds",
+  "type": "integer"
+}

First observedSep 25, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the destructive/open-world annotations, the description discloses overwrite behavior, returned fields, conflict inspection, arbiter failure fallback, LLM cost implications, pending-request behavior, and blocking behavior for rule-based merges. These are substantive operational details not already covered by the annotations.

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 purpose and key constraints are front-loaded, and the length is justified by the tool's complexity. However, the description is dense and somewhat run-on in places, with several clauses that could be split for easier scanning.

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?

Given the complexity, annotations, and output schema, the description is complete enough for correct invocation. It covers destructive overwrite risk, arbitration delegation, fallback behavior, and the fact that callers should inspect warnings and fusion method.

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 schema already documents all five parameters. The description still adds useful semantics, especially how arbitration_model='auto' interacts with use_platform_models and how rule-based merges block without a model call.

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?

The description uses a specific verb and resource: "Fuse two or more records of the same entity into a new arbitration record." It also explicitly bounds the scope with "not to merge different entities," which distinguishes it from merging unrelated records or concepts.

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?

It states when to use the tool ("after separately recovered model runs") and when not to use it ("not to merge different entities"). It also distinguishes the rule-based path from the arbitration-model path and explains the arbitration delegation behavior, giving clear selection guidance.

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

All Entity Enricher 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.