Entity Enricher

Create database sync

create_database_sync

Register a saved schema for relational synchronization to PostgreSQL, MySQL or SQLite. Requires owner and a sync-enabled plan. Starts a billed classification job when available; returns database ID, classification_job_id or classification_skipped, stamped_keys and registration_notices. The webhook signing secret stays outside the MCP response and can be managed in the web app. The schema is initially unpublished: wait for classification, review keys/options/notices, then publish_schema before any data can sync. pk_strategy locks once the physical model ships. Owned child arrays replace previous membership, so omitted children are deleted on re-enrichment. purge_entity_state transfers custody to replicas; relay custody_warning. A connected host may provision automatically; otherwise get_database_setup_instructions starts browser-confirmed client pairing. Modeling, publication and delivery: enricher://docs/database-sync.

Input Schema

Name	Required	Description	Default
`name`	Yes	Name of the physical database (existing on the user's server, or created by `ee-database run --create-missing`); shared by every schema linked to this database sync. Also used (snake-cased) as the conventional replica database name by the ee-database CLI.
`dialect`	No	SQL dialect the deltas are rendered in: postgres \| mysql \| sqlite.	postgres
`on_gaps`	No	Admission gate — what is written when an enrichment has gaps (non-nullable fields unfilled). 'reject_entity': nothing — one gap anywhere refuses the whole enrichment. 'skip_children' (default): the entity without its incomplete children — an array item is dropped, a shared 1-1 reference is detached (child not written, parent's foreign key NULL); gaps with no such child above them still reject. 'accept_partial': everything — gaps land as NULLs, and under last-write-wins a later partial run erases what an earlier one filled.	skip_children
`schema_id`	Yes	Saved schema UUID to connect the database to.
`pk_strategy`	No	surrogate (default): physical surrogate IDs with unique schema keys; natural: use schema keys as physical primary keys and restrict later re-keying. Locks once the physical model ships; decide before publication. See enricher://docs/database-sync.	surrogate
`target_host`	No	Sync host (id or name) that should provision and sync this registration automatically (managed ee-database mode). Omitted: auto-assigned when exactly one eligible host is connected; otherwise the response's connected_hosts lists the candidates — relay the choice to the user and call assign_sync_host, or fall back to get_database_setup_instructions for browser-confirmed manual pairing.
`key_language`	No	Language of multilingual identity tokens (ISO 639-1), shared by all schemas of this database. Usually defaults to schema language when needed; publication may request it after classification. Locked once chosen for the database.
`purge_on_ack`	No	Delete delivered delta copies once acknowledged.
`index_scalars`	No	none: identity/feed indexes; keys: add natural keys and relation access paths; filterable (default): add dates, search intent, spatial/range roles and entity query indexes; all: every scalar. Later changes queue index migrations.	filterable
`notify_debounce_s`	No	Quiet period (seconds) before a delta-available notification fires: each new delta resets the timer, so a burst is announced once. Default 5 for MCP callers (agent workflows expect near-immediate reaction); the web app defaults to 30 to coalesce human-scale editing bursts.
`propagate_not_null`	No	Mirror required schema fields as SQL NOT NULL. Omitted: on for strict gap policies, off for accept_partial. True with accept_partial is refused. Later tightening requires validating existing replica rows; violations can quarantine the migration.
`purge_entity_state`	No	Delete fully delivered entity state after every linked database acknowledges it. Transfers custody to replicas, makes server snapshots incomplete and limits duplicate checks. Relay custody_warning and obtain agreement before enabling. Default false.
`use_platform_models`	No	By default (false) the registration's classification pass runs on YOUR model: its calls come back as pending requests on classification_job_id, to answer with answer_llm_request; no credits are consumed. true runs it on the platform (billed). Protocol: enricher://docs/llm-delegation.
`purge_on_ack_delay_days`	No	Grace period for purge_on_ack: keep acknowledged delta copies this many days (from acknowledgement) before the hourly purge deletes them. Omit to delete them at acknowledgement. Bounded by the plan's delta retention ceiling.
`pattern_index_localized_keys`	No	Add per-language pattern-match indexes on indexed localized keys/labels (default false). Useful for prefix autocomplete; increases write/index cost. Concrete SQL depends on the selected dialect.
`purge_entity_state_delay_days`	No	Grace period for purge_entity_state: a fully-delivered entity row is kept until it has gone this many days without an update, then the hourly purge deletes it. Omit to delete it as soon as every database of the schema acknowledged it.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 27, 2026

removedInput schema / properties / delegate_llm_calls

Removed value: -{
-  "default": false,
-  "description": "Run the registration's classification pass on YOUR model: its calls come back as pending requests on classification_job_id, to answer 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": "By default (false) the registration's classification pass runs on YOUR model: its calls come back as pending requests on classification_job_id, to answer with answer_llm_request; no credits are consumed. true runs it on the platform (billed). 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 the registration's classification pass on YOUR model: its calls come back as pending requests on classification_job_id, to answer with answer_llm_request; no credits are consumed. 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?

Beyond annotations, the description discloses important behavior: billing implications of classification, return fields, webhook secret exclusion, initial unpublished state, pk_strategy locking, replacement semantics for owned child arrays, purge custody transfer, and the custody_warning relay requirement. These are material behavioral traits an agent needs before invoking a creation tool with side effects.

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 description is front-loaded with the core purpose and packs necessary workflow, side effects, and alternatives into a dense paragraph. It is appropriate for a 16-parameter creation tool, though the density is high and some clauses could be easier to scan with stronger structure.

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, rich input schema, annotations, and output schema, the description covers the key missing context: prerequisites, return fields, publication workflow, host provisioning paths, locking behavior, purge warnings, and documentation links. An agent has enough information to call the tool correctly and know what to do next.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already carries the parameter documentation burden. The description mentions some parameter consequences (pk_strategy locking, purge_entity_state custody transfer, target_host provisioning), but these largely restate the schema rather than adding substantial new semantic detail.

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: registering a saved schema for relational synchronization to PostgreSQL, MySQL, or SQLite. It clearly distinguishes creation from sibling operations like list_database_syncs, delete_database_sync, sync_records_to_database, and publish_schema.

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 explains prerequisites (owner and sync-enabled plan), the post-creation workflow (wait for classification, review keys/options/notices, then publish_schema before sync), and alternatives for host provisioning (assign_sync_host or get_database_setup_instructions). This gives an agent explicit routing guidance rather than leaving usage to inference.

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.