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

TableJSON Schema

Name	Required	Description	Default
`model`	No	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.	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).
`enable_web_search`	No	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.
`naming_convention`	No	auto \| snake_case \| camelCase	auto

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

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

Behavior5/5

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

Annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) only sketch the safety profile; the description adds substantial non-obvious behavior — requires editor role, generation is billed, returns a job_id that may already be paused or complete, and the pause/clarify path via answer_job_question or get_job_status. That is real context beyond the structured fields.

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 purpose and mode rules, then constraints, then routing. It is dense but nearly every clause carries a distinct constraint; only the docs pointer at the end feels like it could be trimmed, keeping it short of a 5.

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 an 11-parameter async generation tool with an output schema present, the description supplies the missing operational context — billing, editor requirement, async pause/poll handling, and the review-before-create_schema_from_sample step — so nothing essential to a correct call is left out.

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% and the parameter docs are already thorough (model, request, language, sample_count, attachments, typical_objects, existing_samples all explained inline). The description largely restates these rules ('set sample_count separately from request', 'Attachments force one sample') rather than adding syntax or format detail the schema lacks, so baseline 3 applies.

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+resource ('Generate editable sample JSON from a free-text request for schema authoring') and immediately distinguishes the two operating modes (knowledge vs. attachment/source). It also names the downstream sibling (create_schema_from_sample), so an agent can place it precisely in the workflow.

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?

Gives explicit when-to-use rules: without attachments use model knowledge and optional web search; with attachments extract from sources only and search does not relax that. It also states when to set sample_count separately, that attachments force one sample, and routes relationship/hybrid cases to specific docs.

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.