Entity Enricher

Classify database model

classify_database_model

Start a billed analysis proposing database keys, SQL types, indexes and relationship ownership on a linked schema. Requires editor. Registration already starts the initial pass; use this after relevant edits. Incremental scope covers new properties or changed JSON types/multilingual flags; an empty scope does not rerun unchanged fields. Returns job_id: poll get_job_status and inspect get_schema's working copy. Correct proposals with property tools, then publish_schema to ship changes. Entity-level indexes and ownership choices: enricher://docs/database-sync.

Input Schema

Name	Required	Description	Default
`model`	No	Model composite key; leave it on auto (the default). auto is YOUR model, or with use_platform_models=true the organization's best model for this task 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. Name a provider::model only when the user named one; that runs the job on the platform (billed). Keys: list_models. On the platform, auto runs the schema's own model (set at generation or in the schema editor), else the best schema-generation model.	auto
`schema_id`	Yes	Saved schema UUID to classify.
`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.

Changed1 schema field changedOct 30, 2026

changedInput schema / properties / model / description

Previous value: -"Model composite key; leave it on auto (the default). auto is YOUR model, or with use_platform_models=true the organization's best model for this task 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. Name a provider::model only when the user named one; that runs the job on the platform (billed). Keys: list_models. On the platform the task is schema generation; with no scored model, auto falls back to the model that generated the schema."New value: +"Model composite key; leave it on auto (the default). auto is YOUR model, or with use_platform_models=true the organization's best model for this task 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. Name a provider::model only when the user named one; that runs the job on the platform (billed). Keys: list_models. On the platform, auto runs the schema's own model (set at generation or in the schema editor), else the best schema-generation model."

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

changedInput schema / properties / model / description

Previous value: -"Model composite key. 'auto' (default) lets the server pick the org's default schema-generation model, falling back to the model that generated the schema."New value: +"Model composite key; leave it on auto (the default). auto is YOUR model, or with use_platform_models=true the organization's best model for this task 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. Name a provider::model only when the user named one; that runs the job on the platform (billed). Keys: list_models. On the platform the task is schema generation; with no scored model, auto falls back to the model that generated the schema."

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.4/5.0

Behavior4/5

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

Goes well beyond the annotations by disclosing cost ('billed analysis'), the required role, incremental-vs-full analysis semantics, and the polling/output contract. The one flaw is the unconditional 'billed' framing, which sits awkwardly against the schema's statement that the default use_platform_models=false consumes no credits and parks calls as pending requests — an agent could wrongly assume default invocation is paid.

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 the core action and cost, then prerequisites, then the call→poll→correct→publish workflow, with a docs pointer at the end. Dense but nearly every clause carries operational information; the mid-sentence pivot into 'incremental scope' wording is the only slightly tangled part.

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, the description still tells the agent what comes back (job_id) and how to consume it asynchronously, plus role requirements, cost model, and the full downstream workflow. Nothing needed to invoke this correctly is missing.

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 model, schema_id and use_platform_models are already fully documented — baseline 3 applies. The description adds model-agnostic framing but does not clarify parameters further, and it references an 'incremental scope' that has no corresponding parameter in the schema, which could send an agent looking for a control that does not exist.

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 a billed analysis proposing database keys, SQL types, indexes and relationship ownership on a linked schema'), which is far more precise than the sibling analyze_schema or publish_schema. It also delineates it from registration ('Registration already starts the initial pass'), so an agent knows exactly which stage this tool occupies.

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?

Explicit triggering condition ('use this after relevant edits'), explicit exclusion ('an empty scope does not rerun unchanged fields' — do not call when nothing changed), prerequisite ('Requires editor'), and a complete follow-up path: poll get_job_status, inspect get_schema's working copy, correct via property tools, then publish_schema.

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.