Skip to main content
Glama

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
NameRequiredDescriptionDefault
modelNoAuto (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
requestNoEntity 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.
languageNoOutput 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_answerNoOmit or false to pause for clarification; true authorizes standard interpretations and planner defaults without asking, in either mode.
sample_countNoNumber 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_secondsNoHow long to wait for the first pause or completion before returning (0 = return the job_id immediately).
attachment_idsNoUUIDs 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_objectsNoUp 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.
enable_web_searchNoUse 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_conventionNoauto | snake_case | camelCaseauto

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Beyond the annotations, the description discloses that generation requires an editor, is billed, returns a job_id, and may already be paused or complete. It also warns that attachments force one sample, source mode is strict, and the agent must not silently change facts or structure. This is substantial behavioral context the annotations do not provide.

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 dense but every sentence earns its place: purpose, mode rules, billing/editor requirement, job lifecycle, review obligation, and advanced doc pointers. It is front-loaded with the core purpose and then layers necessary workflow detail without repetition.

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 10 parameters and a complex asynchronous workflow, the description covers the full call path: modes, attachments, job_id return, pause/completion states, next-step tools, and warnings. An output schema exists, so return values need no further explanation, and advanced cases are routed to documentation.

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, but the description adds cross-parameter meaning: sample_count must be set separately from request, each sample is one instance in one language, attachments force one sample, and typical_objects anchors knowledge mode. These clarifications help an agent use the parameters together correctly.

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 verb and resource: 'Generate editable sample JSON from a free-text request for schema authoring.' It clearly distinguishes this from downstream siblings like create_schema_from_sample and get_job_status, so an agent knows exactly what this tool produces.

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?

The description gives explicit mode-based guidance: without attachments use model knowledge and optional web search; with attachments extract from sources only and search does not relax that. It also names the exact alternatives for follow-up actions: answer_job_question for pauses, get_job_status for polling, and create_schema_from_sample after review, plus doc links for advanced relationship modeling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.