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

TableJSON 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.
`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

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 25, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Despite sparse annotations, the description discloses many non-obvious side effects: it starts a billed classification job, leaves the schema initially unpublished, locks pk_strategy once the physical model ships, replaces owned child arrays on re-enrichment, and transfers custody for purge_entity_state. It also warns that the webhook signing secret is not returned and instructs relaying custody_warning. This goes far beyond what the annotations convey and does not contradict them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but information-dense: each sentence introduces a distinct fact such as prerequisites, billing, return fields, unpublished state, key locks, child replacement, purge semantics, host provisioning, and a docs pointer. It is front-loaded with the core registration purpose before moving to follow-up behavior. No filler sentences are present, so the length is justified for a tool with this many parameters and side effects.

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?

For a tool with this many parameters and external effects, the description covers all major decision points: plan requirements, billing, lifecycle, locks, child replacement, purge custody, host provisioning, and documentation. The output schema exists and the description still lists the primary return fields. It is complete enough for an agent 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?

The input schema already documents all 15 parameters with 100% coverage, so the baseline is 3 and the description does not need to repeat parameter details. The description adds lifecycle context around pk_strategy locking and purge_entity_state custody transfer, but these largely echo the schema's own parameter descriptions. It therefore adds marginal parameter-level value without needing compensation.

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 opens with a specific action and object: register a saved schema for relational synchronization to PostgreSQL, MySQL or SQLite. This makes the tool's scope unambiguous and distinguishes it from siblings like create_schema_from_sample, publish_schema, and get_database_setup_instructions by centering on registration of an existing schema. The billing and publication lifecycle details reinforce the purpose rather than obscure it.

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 hard prerequisites: requires owner and a sync-enabled plan. It also lays out the correct workflow: wait for classification, review keys/options/notices, then publish_schema before any data can sync. It names explicit fallbacks such as get_database_setup_instructions for browser-confirmed pairing when no host provisions automatically, so an agent knows when this tool applies versus the surrounding lifecycle tools.

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.