Entity Enricher

Start batch enrichment

start_batch_enrichment

Start billed asynchronous enrichment of an entity list against exactly one of schema_id or target_schema. Returns job_id and total. No fixed entity-count cap; live prompt quotas and credits can stop remaining work. Each entity follows the enrichment/fusion pipeline; every model must succeed for its automatic fusion and database admission. A confident classification mismatch skips that entity without enrichment, never pauses the batch. Poll get_job_status, then list_records(job_id=...). Attachments apply to every entity. Unlike enrich_entity, this tool does not expose database_sync=false. By default the job runs on YOUR model (use_platform_models=false, no explicit model): its entities park their calls as llm_requests, several at once, and enable_web_search must be decided (omitted returns web_search_undecided). Input contracts, partial results and recovery: enricher://docs/batch-enrichment.

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": {
      "entities": "<entities>"
    },
    "name": "start_batch_enrichment"
  }
}

Input Schema

Name	Required	Description	Default
`models`	No	Model composite keys; omit (or pass ['auto']) for one automatically selected model: YOUR model, or with use_platform_models=true the organization's best model for enrichment from its benchmark scores (quality/speed/cost weights), within the run's constraints (attachments, web search, thinking) — the result reports the pick as model_selection. auto alone never fuses. Name provider::model keys only when the user named them; that runs the job on the platform (billed), and two or more fuse. Keys and model-count limits: list_models.
`entities`	Yes	Entities to enrich (each a free-form dict naming the entity — the schema's identifying fields ideally, but any field names work).
`strategy`	No	auto (default) \| single_pass \| expert_domains \| multi_expertise	auto
`languages`	No	ISO 639-1 codes; defaults to ['en'].
`schema_id`	No	UUID of a saved schema. Mutually exclusive with target_schema.
`target_schema`	No	Inline schema document in the supported Entity Enricher dialect. Prefer schema_id to link records. See enricher://docs/schema-reference.
`attachment_ids`	No	Attachment UUIDs applied as source material to every entity.
`reasoning_effort`	No	Thinking (reasoning) opt-in: low, medium or high; omitted = off. On the platform, auto then picks only a model whose reasoning the platform can pilot, and the effort is translated per provider. On YOUR model, apply the effort yourself when you run the requests.
`arbitration_model`	No	Optional LLM for auto-fusion conflict resolution (None = rule-based).
`enable_web_search`	No	On your model (the default), true asks you to ground the answers with your own web search tool and false not to; omitted returns web_search_undecided so you ask the user first. On platform models, true enables the provider's builtin search where the model supports it (omitted = false).
`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.
`classification_model`	No	Optional classifier key. Confident mismatches skip that entity; softer verdicts become prompt context. Batch classification never pauses.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 27, 2026

removedInput schema / properties / delegate_llm_calls

Removed value: -{
-  "default": false,
-  "description": "Run every LLM call of this job on YOUR model instead of a platform model: the job parks each call as a pending request you answer with answer_llm_request; no credits are consumed. Model parameters must then be omitted or 'auto'. Plan feature. Protocol: enricher://docs/llm-delegation.",
-  "title": "Delegate Llm Calls",
-  "type": "boolean"
-}

addedInput schema / properties / enable_web_search

Added value: +{
+  "anyOf": [
+    {
+      "type": "boolean"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "On your model (the default), true asks you to ground the answers with your own web search tool and false not to; omitted returns web_search_undecided so you ask the user first. On platform models, true enables the provider's builtin search where the model supports it (omitted = false).",
+  "title": "Enable Web Search"
+}

changedInput schema / properties / models / description

Previous value: -"Model composite keys (call list_models to discover them). Optional: omit (or pass ['auto']) to let the server pick the org's default model — pinned per-task default if set, else the best blended benchmark score."New value: +"Model composite keys; omit (or pass ['auto']) for one automatically selected model: YOUR model, or with use_platform_models=true the organization's best model for enrichment from its benchmark scores (quality/speed/cost weights), within the run's constraints (attachments, web search, thinking) — the result reports the pick as model_selection. auto alone never fuses. Name provider::model keys only when the user named them; that runs the job on the platform (billed), and two or more fuse. Keys and model-count limits: list_models."

addedInput schema / properties / reasoning_effort

Added value: +{
+  "anyOf": [
+    {
+      "enum": [
+        "low",
+        "medium",
+        "high"
+      ],
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Thinking (reasoning) opt-in: low, medium or high; omitted = off. On the platform, auto then picks only a model whose reasoning the platform can pilot, and the effort is translated per provider. On YOUR model, apply the effort yourself when you run the requests.",
+  "title": "Reasoning Effort"
+}

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"
+}

Changed1 schema field changedOct 22, 2026

addedInput schema / properties / delegate_llm_calls

Added value: +{
+  "default": false,
+  "description": "Run every LLM call of this job on YOUR model instead of a platform model: the job parks each call as a pending request you answer with answer_llm_request; no credits are consumed. Model parameters must then be omitted or 'auto'. Plan feature. Protocol: enricher://docs/llm-delegation.",
+  "title": "Delegate Llm Calls",
+  "type": "boolean"
+}

First observedSep 25, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes far beyond annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) by disclosing billing, live quota/credit interruption, per-entity fusion/admission rules, classification-mismatch skipping without pausing, attachment scoping, and the default YOUR-model delegation protocol with parked llm_requests. It even flags that enable_web_search must be decided when omitted. This is unusually rich behavioral disclosure.

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-loads purpose, exclusivity and return values, then moves through behavior, follow-ups and docs. The middle is dense — several clauses are packed into single sentences — but for a 12-parameter asynchronous tool the length is justified and no sentence is clearly wasted.

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?

Even though an output schema exists (so return values needn't be explained), the description covers billing, quotas, model delegation, partial-result recovery and a docs pointer (enricher://docs/batch-enrichment). An agent has enough to call the tool and handle its lifecycle correctly.

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 baseline is 3; the description still adds operational meaning, notably that the default use_platform_models=false path parks calls as llm_requests and that omitted enable_web_search returns web_search_undecided. It largely reinforces schema semantics rather than introducing new ones, so it stops short of a 5.

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?

States a specific verb and resource ('Start billed asynchronous enrichment of an entity list') plus the exclusivity constraint on schema_id/target_schema and the immediate return values. It also distinguishes itself from enrich_entity explicitly ('Unlike enrich_entity, this tool does not expose database_sync=false'), so an agent can differentiate it from siblings without opening the schema.

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?

Gives a concrete follow-up path ('Poll get_job_status, then list_records(job_id=...)') and names the alternative tool with one key behavioral difference. It implies batch-vs-single selection through 'entity list' but never says outright when to prefer enrich_entity over this tool, leaving a small gap.

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.