Entity Enricher

Enrich entity

enrich_entity

Enrich one entity against exactly one of schema_id or target_schema, returning structured output, record_id, costs and any database outcome. Read get_schema's input_contract first (published version when linked); never invent preserve values. Models may be omitted for auto selection. Generation is billed. Two or more models fuse only when all succeed: check failed_models before reporting success. A failed leg prevents automatic fusion and database admission. classification_warning returns success=false, error_code and classification; bypass only after user confirmation. Database sync defaults on: report database.status and database_warning, including partial writes or overwrites; admission is not proof of replica delivery. Recovery and fusion: enricher://docs/enrichment-and-fusion. This tool does not expose web-search activation.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`models`	No	Model composite keys. Omit or pass ['auto'] for one automatically selected model; auto alone never fuses. Use list_models for explicit choices and model-count limits.
`strategy`	No	auto (default — server picks from the schema) \| single_pass (simple schemas, 1 LLM call) \| expert_domains (medium schemas with clear domains) \| multi_expertise (large multi-domain schemas, parallel per-expertise calls — best quality, higher cost)	auto
`languages`	No	ISO 639-1 codes; defaults to ['en'] server-side. The first language is the primary one used for all non-multilingual string fields; multilingual fields get one value per language.
`schema_id`	No	UUID of a saved schema. Mutually exclusive with target_schema.
`entity_data`	Yes	Entity identifiers and supplied values. Read get_schema.input_contract first: preserve paths and keys for supplied array items are required. Identifying field names are guidance; arbitrary names are accepted.
`database_sync`	No	Whether this run feeds the schema's entity layer and linked databases. Leave true for normal enrichments. Set false for the one-model recovery leg of a failed fusion run (see the recovery ladder above): the merge_records call that follows is what should write, so the intermediate single-model write is skipped. The record itself is still saved either way.
`target_schema`	No	Inline JSON Schema document in the supported Entity Enricher dialect; prefer schema_id. Format: enricher://docs/schema-reference.
`attachment_ids`	No	UUIDs of attachments (from upload_attachment) to provide as source material for this enrichment.
`timeout_seconds`	No	Wall-clock cap. Past it the call returns `enrichment_timeout` with the job_id and the job is cancelled — a leg still in flight may finish and persist a partial record, reachable via list_records(job_id=...) and recoverable with retry_expertises. Multi-model fusion runs and reasoning models routinely need more than the default; raise it or use start_batch_enrichment (async).
`arbitration_model`	No	Optional LLM model key used to resolve fusion conflicts when 2+ models are selected. Without this, conflicts are resolved by deterministic voting.
`classification_model`	No	Optional pre-flight classifier model key. When set, the entity is type-checked before enrichment to catch mismatches.
`force_after_classification_warning`	No	Set to true to bypass a previous classification warning. Use only after explicit user confirmation.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 25, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Against sparse annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description carries rich adjacent behavior: generation is billed, fusion occurs only when all models succeed (check failed_models), a failed leg blocks automatic fusion and database admission, database sync defaults on with partial-write/overwrite disclosure, admission does not prove replica delivery, and classification warnings require user confirmation to bypass. It also flags timeout behavior (partial records via job_id). No contradiction with annotations; readOnlyHint=false aligns with the write/database-sync semantics described.

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 front-loaded purpose sentence hits the core contract immediately, and every subsequent sentence earns its place (billing, fusion semantics, database sync, classification warning, recovery doc links). It is a dense wall of text rather than structured paragraphs, but the complexity of a 12-parameter tool with fusion and database-sync semantics justifies the length and density.

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 high complexity (12 params, nested objects, output schema, fusion and database-sync semantics), the description is remarkably complete: it covers single-vs-batch routing, billing, fusion failure modes, database partial writes and replica-delivery caveats, classification-warning bypass, timeout partial-record recoverability, and links to docs (enricher://docs/enrichment-and-fusion, schema-reference). The presence of an output schema relieves the need to explain return values, so nothing critical is missing.

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 and the schema properties already document every parameter. The description nonetheless adds meaning beyond the schema for key params: models ('Two or more models fuse only when all succeed'), database_sync (defaults on, partial writes, admission vs replica delivery), and force_after_classification_warning (bypass only after explicit user confirmation). This elevates it above the baseline, though it doesn't enumerate every parameter.

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 states a specific verb and resource ('Enrich one entity') with precise scoping ('against exactly one of schema_id or target_schema') and the output contract ('structured output, record_id, costs and any database outcome'). The single-entity scope visually distinguishes it from start_batch_enrichment, and references to get_schema, list_models, and retry_expertises orient it among siblings. An agent can tell exactly what this tool does and what it returns.

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?

The description prescribes a prerequisite workflow ('Read get_schema's input_contract first'), an exclusion rule ('never invent preserve values'), and pointers to alternatives (list_models for explicit model choice, start_batch_enrichment for async in the timeout context, retry_expertises for recovery). It does not, however, state an explicit 'use X instead when...' condition for the primary batch alternative in the headline text, leaving some routing inference to the agent.

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.