Skip to main content
Glama

create dataset from logs

create_dataset_from_logs

Curate production gateway logs into training and eval datasets, auto-dropping errored, truncated, duplicate, or human-failed exchanges and applying a quality gate for fine-tuning or evaluation.

Instructions

Curates logged gateway traffic into a managed training dataset (optionally with a disjoint eval holdout split), auto-dropping errored/truncated/empty/duplicate/human-failed/benchmark-contaminated exchanges and applying a chosen quality gate — use it to turn production logs into fine-tuning or eval data. POST /v1/datasets/from_logs (API-key scope: evals:write). Returns: 201 with snake_case: { summary: { total: , kept, dropped: { unparseable, errored, truncated, empty, duplicate, human_failed, contaminated }, folded: { folded_turns, conversations } }, quality: { mode, criterion_id?, criterion_name?, kappa?, human_pass_kept?, ungraded_excluded?, judged?, judge_passed?, judge_failed?, judge_unparsed?, judge_spend_usd? }, training_name, training_count, eval_name?: '-eval', eval_count? }. Notes: Requires an OWNER/ADMIN minting user for dataset creation (403, enforced in the dataset service). 400 (invalid_json) on unparseable JSON. Other 400s: name missing/over 80 chars; unknown quality mode; judge mode without criterion_id; judge criterion not found / trace-unit / misaligned / borderline / unmeasured / drift-flagged / segment-bound but build not scoped to that segment (each eligibility refusal is also written to the refusal ledger, kind dataset_judge_trust); no usable exchanges after curation (nothing created). Fetch is capped at 50,000 most recent matching rows. MONEY: judge mode is gated up front at ~$0.02 per conversation to judge (402 'Insufficient balance for judge gating' before any spend) and every judge call is then metered as usage; a scoring failure mid-run FAILS THE WHOLE BUILD (no dataset created) but rows already judged were billed (idempotent ids — retry does not re-bill). Human FAIL grades (or rows sharing an agent run with a trace-scoped FAIL) never enter a dataset in any mode. Multi-turn chats are folded into one weighted line per conversation. If the training set is created but the eval split fails, the response is a 400 that says the training dataset already exists. The eval split shares no example with the training set, so it is valid as an eval source (POST /v1/evals with sample_filters.dataset_id).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesDataset name, 1-80 chars after trimming. Also used as the file name ('<name>.jsonl') and, with holdout_pct, the eval split is named '<name>-eval'.
filtersNoWhich logged traffic feeds the build. Nested keys: model (string, exact model name), tag (string, the task label sent as X-Omnia-Tag), segment (string, an auto-detected traffic segment / prompt family as shown on GET /v1/logs rows), finish_reason (string), cache_hit (boolean), start (integer unix seconds, inclusive lower bound), end (integer unix seconds). Falsy values (empty string, 0) are ignored. Success-only is always enforced regardless of filters.
qualityNoThe quality ladder: { mode: 'cleaned'|'graded'|'judge', criterion_id?: string }. 'cleaned' (default) = mechanical curation only. 'graded' = keep only exchanges a human graded pass (free). 'judge' = a CALIBRATED judge (criterion_id REQUIRED; request-unit; trust 'trustworthy' or 'under-measured'; not drift-flagged; if segment-bound, filters.segment must equal its segment) keeps only passing conversations, judged at each conversation's terminal turn; human grades override the judge for free. mode must be a string, criterion_id a string when present.
sourcesNoInclude-list of source models: { models: string[] }. Only exchanges served by these models feed the build; an empty array means no restriction. Each item must be a non-empty string, else 400 'sources.models must be an array of model names'.
holdout_pctNoPercentage (0-50) of curated lines carved into a second, DISJOINT '<name>-eval' dataset linked back to the training set. 0/omitted = no eval split. Values above 50 are capped at 50.
decontaminateNoDrop rows whose prompt shares a 13-word shingle with a public benchmark test split. Default true. Only an explicit boolean is honored. The provenance records what was checked; an unavailable index is recorded as 'not checked', never as clean.
Install Server

TDQS

A4.5/5.0
Behavior5/5

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

This is an exceptionally transparent description. It discloses auto-drop categories, the 50,000 row fetch cap, judge-mode billing and gating, failure-of-whole-build semantics, idempotent retry billing, eval-split failure behavior, disjointness guarantees, and human-FAIL exclusion. These details go far beyond what the sparse annotations (readOnlyHint/idempotentHint/destructiveHint) convey.

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

Conciseness3/5

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

Every sentence carries real content and the length is arguably justified by the tool's complexity, but the description is one dense wall of text with critical constraints buried in the middle. It would benefit from structured sections or bullets for billing, error cases, and prerequisites, and the most important usage guidance could be front-loaded more clearly.

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 there is no output schema, the description supplies a detailed response shape, error statuses, auth requirements, failure modes, billing caveats, and edge cases like contamination and refusal ledgers. An agent has nearly everything needed to call this tool correctly and predict what will happen on success or failure.

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 coverage is 100% and the schema descriptions are already rich, so the baseline is 3. The description adds meaningful non-obvious consequences: the fetch cap, judge spending and billing behavior, no re-billing on retry, eval split naming, and the fact that a failed eval split still leaves the training set created. These details help an agent reason about parameter impact beyond 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?

The description opens with a specific verb and resource ('Curates logged gateway traffic into a managed training dataset') and immediately distinguishes this from related tools like create_eval or upload_training_file by describing the source, the curation action, and the optional eval split. It also gives the concrete endpoint and auth scope, so an agent knows exactly what this operation is.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use the tool ('use it to turn production logs into fine-tuning or eval data') and states critical prerequisites such as OWNER/ADMIN minting and evals:write scope. It does not explicitly name alternative tools or say 'use X instead', but the context is strong enough for an agent to determine appropriate use.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/omnia-v/errorbar-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server