Entity Enricher

Generate sample

generate_sample

Generate editable sample JSON from a free-text request for schema authoring. Without attachments, use model knowledge and optional web search; with attachments, extract from the sources only (search does not relax that rule). Each sample is one instance in one language; set sample_count separately from request. Attachments force one sample. Requires editor; generation is billed. Returns a job_id and may already be paused or complete: relay pause questions through answer_job_question, otherwise poll get_job_status. Review returned samples and warnings before create_schema_from_sample; do not silently change facts or structure. For relationship modeling, multiple documents or hybrid extraction plus research, read enricher://docs/schema-from-sample and enricher://docs/documents.

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. An explicit model bypasses the capability matching; provider combinations or quota may still fail.	auto
`request`	No	Entity type, desired fields, scope and size/depth budget. Required without attachments; optional source-mode instructions otherwise. Put the number of instances in sample_count, not in this text.
`language`	No	Output language code for the generated field names AND values (e.g. 'en', 'fr'); an explicit code applies even when attachments are in another language. Omitted (default) → the generator follows the language the request is written in (its text and any typical object), else the attachment's, else English.
`auto_answer`	No	Omit or false to pause for clarification; true authorizes standard interpretations and planner defaults without asking, in either mode.
`sample_count`	No	Number of same-type instances (1..20), default 1. Consider 3 varied instances when designing a schema. Attachments force 1. Inspect samples_note for under-delivery or the cap.
`wait_seconds`	No	How long to wait for the first pause or completion before returning (0 = return the job_id immediately).
`attachment_ids`	No	UUIDs from upload_attachment. Providing any attachment switches the call into source mode: transcribe the document or describe visible photo attributes only, with an interactive planner.
`typical_objects`	No	Up to sample_count concrete instances to anchor knowledge mode (e.g. ['Sanofi', 'Pfizer']), one per generated sample in order — slots beyond len(typical_objects) are named by the model's own instance roster. In source mode the attachment remains authoritative and this is ignored.
`existing_samples`	No	Samples you already hold, to extend instead of starting over: the new samples reproduce the first one's exact field set and never repeat an instance already in the set; sample_count is then the number of NEW samples (set capped at 20 in total), request is optional context, and only the new samples are returned. Knowledge mode only (no attachments).
`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.
`enable_web_search`	No	Knowledge mode only; source mode (attachments) remains source-only. On your model (the default), true asks you to ground the samples 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 uses the provider's builtin search (omitted = false; ignored on an unsupported explicit model). Hybrid tasks: enricher://docs/documents.
`naming_convention`	No	auto \| snake_case \| camelCase	auto
`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.

Changed8 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 / anyOf

Added value: +[
+  {
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / enable_web_search / default
```
Previous value: -falseNew value: +null
```

changedInput schema / properties / enable_web_search / description

Previous value: -"Use builtin search in knowledge mode (default false). Source mode remains source-only. With an explicit unsupported model this option is ignored. Hybrid tasks: enricher://docs/documents."New value: +"Knowledge mode only; source mode (attachments) remains source-only. On your model (the default), true asks you to ground the samples 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 uses the provider's builtin search (omitted = false; ignored on an unsupported explicit model). Hybrid tasks: enricher://docs/documents."

removedInput schema / properties / enable_web_search / type
```
Removed value: -"boolean"
```

changedInput schema / properties / model / description

Previous value: -"Auto (default) chooses the organization task model with attachment/search capabilities. Explicit provider::model bypasses this capability matching; provider combinations or quota may still fail."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. An explicit model bypasses the capability matching; provider combinations or quota may still fail."

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

Changed1 schema field changedOct 5, 2026

addedInput schema / properties / existing_samples

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "maxItems": 19,
+      "minItems": 1,
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Samples you already hold, to extend instead of starting over: the new samples reproduce the first one's exact field set and never repeat an instance already in the set; sample_count is then the number of NEW samples (set capped at 20 in total), request is optional context, and only the new samples are returned. Knowledge mode only (no attachments).",
+  "title": "Existing Samples"
+}

First observedSep 25, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare readOnlyHint=false, openWorldHint=true, destructiveHint=false; the description goes far beyond by disclosing the editor requirement, that generation is billed, that it runs as a job which may return already paused or complete, that no credits are consumed when running on YOUR model, and that samples must not have facts silently changed.

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-loaded with the core purpose and mode split before the job-flow instructions, and nearly every sentence carries operational weight. It is dense and long, but density is justified by the 13-parameter, two-mode surface; a couple of clauses (e.g. the repeated source-only reminder) could be trimmed.

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 complex, dual-mode job tool with 13 parameters and an output schema, the description covers what the output schema cannot: async job lifecycle, pause handling, billing implications, and the hand-off to create_schema_from_sample. Nothing an agent needs to call this correctly 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 description coverage is 100%, so the baseline is 3; the description earns extra credit by adding cross-parameter rules the schema does not state — instance count belongs in sample_count not request, each sample is one instance in one language, and any attachment forces one sample. Remaining params (model, auto_answer, wait_seconds) are explained only in the schema.

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?

Opens with a specific verb+resource+output ('Generate editable sample JSON ... for schema authoring') and immediately frames the two operating modes (knowledge vs. attachment/source). An agent can tell it apart from sibling create_schema_from_sample (consumes samples) and analyze_sample (inspects them) without opening any 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?

Explicit routing: use answer_job_question for pause questions, otherwise poll get_job_status; review samples and warnings before calling create_schema_from_sample; read enricher://docs/schema-from-sample for relationship modeling or multi-document work. It also states the when-not condition (attachments force one sample, search does not relax source-only extraction).

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.