Skip to main content
Glama

create_training_job

Quote a wake-word training job (free; nothing trains until paid). Returns a job_token (STORE IT — the only credential) and a binding CHF price. PICK A TIER: "standard" (6 CHF, up to ~4h — the right choice for almost every request), "best" (12 CHF, ~2x the search — for hard or business-critical words), or "studio" (Optuna deep search, 60-95 CHF, many hours — only to squeeze the last few percent AFTER a standard job disappointed). Same three options a human gets on the website, same prices. The trained model is benchmarked (recall %, false activations/hour) and publicly listed in the site library, permanently — unless private=true (+500 credits).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tierNoRECOMMENDED — pick one instead of tuning parameters. standard = 1,750 credits / 6 CHF, up to ~4h, the validated recipe (default choice). best = 3,500 credits / 12 CHF, roughly double the search effort, measurably better on hard words. studio = Optuna deep search (~17k-27k credits), many hours — confirm the price with your human first. Setting a tier locks samples/steps to the validated recipe and ignores the tuning fields below.
engineYesTarget engine. 'openwakeword': desktop / Raspberry Pi / Python (ONNX+TFLite, `pip install openwakeword`). 'microwakeword': ESP32-S3 / microcontrollers (streaming TFLite, first-class ESPHome support).
optunaNoLEGACY — prefer tier="studio", which works on BOTH engines. PREMIUM deep search, openwakeword only (~48 CHF default vs ~5.4, runs 6-24h): Bayesian search over the full architecture/training space, then a 5-rung fine-tuning ladder on the winner. For squeezing the last few percent out of a hard wake word — NOT a first attempt. Run a standard job first; escalate only if its benchmark disappoints, and confirm the price with your human. Ignores training_steps (the search sweeps it).
privateNo+500 credits: model is never listed anywhere and is retrievable ONLY with the job_token, with no time limit (the token is the single key — losing it loses the model). Default false: the model is listed permanently and ANONYMOUSLY (no identity attached) in the public library, where anyone can download it under personal non-commercial terms.
languagesNoTTS voice mix, e.g. [{"code":"en_US","percentage":100}]. Default English. ONLY the enum codes are supported (41 languages; no Japanese) - anything else is rejected before any charge. Non-English costs more on openwakeword.
n_samplesNoSynthetic positives, default 200000 (recommended).
wake_wordYesPhrase to detect, e.g. 'hey aurora'
optuna_trialsNoOptuna only: Bayesian search trials before the ladder, 5-30 (default 20). Price scales linearly with trials.
training_stepsNoLEGACY (ignored when tier is set). Default 80000 (openwakeword) / 20000 (microwakeword).
augmentation_roundsNoDefault 1 (openwakeword) / 3 (microwakeword).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / languages / description
      Previous value: -"TTS voice mix, e.g. [{\"code\":\"en_US\",\"percentage\":100}]. Default English. Non-English costs more on openwakeword."New value: +"TTS voice mix, e.g. [{\"code\":\"en_US\",\"percentage\":100}]. Default English. ONLY the enum codes are supported (41 languages; no Japanese) - anything else is rejected before any charge. Non-English costs more on openwakeword."
    • addedInput schema / properties / languages / items / properties / code / enum
      Added value: +[
      +  "ar_JO",
      +  "ca_ES",
      +  "cs_CZ",
      +  "cy_GB",
      +  "da_DK",
      +  "de_DE",
      +  "el_GR",
      +  "en_GB",
      +  "en_US",
      +  "es_ES",
      +  "es_MX",
      +  "fa_IR",
      +  "fi_FI",
      +  "fr_FR",
      +  "hi_IN",
      +  "hu_HU",
      +  "is_IS",
      +  "it_IT",
      +  "ka_GE",
      +  "kk_KZ",
      +  "lb_LU",
      +  "lv_LV",
      +  "ml_IN",
      +  "ne_NP",
      +  "nl_BE",
      +  "nl_NL",
      +  "no_NO",
      +  "pl_PL",
      +  "pt_BR",
      +  "pt_PT",
      +  "ro_RO",
      +  "ru_RU",
      +  "sk_SK",
      +  "sl_SI",
      +  "sr_RS",
      +  "sv_SE",
      +  "sw_CD",
      +  "tr_TR",
      +  "uk_UA",
      +  "vi_VN",
      +  "zh_CN"
      +]
  2. Changed3 schema fields changed
    • changedInput schema / properties / optuna / description
      Previous value: -"PREMIUM deep search, openwakeword engine only (~48 CHF default vs ~5.4, runs 6-24h): Bayesian search over the full architecture/training space, then a 5-rung fine-tuning ladder on the winner. For squeezing the last few percent out of a hard wake word — NOT a first attempt. Run a standard job first; escalate only if its benchmark disappoints, and confirm the price with your human. Ignores training_steps (the search sweeps it)."New value: +"LEGACY — prefer tier=\"studio\", which works on BOTH engines. PREMIUM deep search, openwakeword only (~48 CHF default vs ~5.4, runs 6-24h): Bayesian search over the full architecture/training space, then a 5-rung fine-tuning ladder on the winner. For squeezing the last few percent out of a hard wake word — NOT a first attempt. Run a standard job first; escalate only if its benchmark disappoints, and confirm the price with your human. Ignores training_steps (the search sweeps it)."
    • addedInput schema / properties / tier
      Added value: +{
      +  "description": "RECOMMENDED — pick one instead of tuning parameters. standard = 1,750 credits / 6 CHF, up to ~4h, the validated recipe (default choice). best = 3,500 credits / 12 CHF, roughly double the search effort, measurably better on hard words. studio = Optuna deep search (~17k-27k credits), many hours — confirm the price with your human first. Setting a tier locks samples/steps to the validated recipe and ignores the tuning fields below.",
      +  "enum": [
      +    "standard",
      +    "best",
      +    "studio"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / properties / training_steps / description
      Previous value: -"Default 80000 (openwakeword) / 20000 (microwakeword) — the validated recipes."New value: +"LEGACY (ignored when tier is set). Default 80000 (openwakeword) / 20000 (microwakeword)."
  3. Changed2 schema fields changed
    • addedInput schema / properties / optuna
      Added value: +{
      +  "description": "PREMIUM deep search, openwakeword engine only (~48 CHF default vs ~5.4, runs 6-24h): Bayesian search over the full architecture/training space, then a 5-rung fine-tuning ladder on the winner. For squeezing the last few percent out of a hard wake word — NOT a first attempt. Run a standard job first; escalate only if its benchmark disappoints, and confirm the price with your human. Ignores training_steps (the search sweeps it).",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / optuna_trials
      Added value: +{
      +  "description": "Optuna only: Bayesian search trials before the ladder, 5-30 (default 20). Price scales linearly with trials.",
      +  "type": "integer"
      +}
  4. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the minimal annotations (all false), the description discloses the essential behavioral traits: the operation is free and creates no training until paid, it returns a job_token that is 'the only credential', prices are binding, and trained models are benchmarked and publicly listed permanently unless private=true. This is precisely the kind of non-obvious behavior an agent needs to avoid surprises.

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?

The description is front-loaded with the core purpose and key caveat, then organized into tier guidance and disclosure of output/publication behavior. It is longer than average but every sentence carries a distinct fact (token, price, tier purpose, public listing, private option), so it earns its length.

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?

With no output schema, the description explicitly names the two return values an agent must preserve (job_token and binding CHF price) and explains the default publication outcome. Combined with 100% schema parameter coverage and sibling tools covering payment/status, nothing essential about calling this tool 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 coverage is 100% and the schema descriptions are already rich (tier credits/prices, engine use cases, optuna legacy note, private consequences, language enum restriction). The tool description repeats and reframes some of the same tier guidance but adds little new information beyond what the schema already provides, so it stays at the baseline for high schema coverage.

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 precise verb-object pair: 'Quote a wake-word training job', and immediately clears the key ambiguity by stating it is free and nothing trains until paid. This distinguishes it from sibling tools like pay_training_job or get_training_job, and the tier breakdown clarifies exactly what the 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 Guidelines4/5

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

The description explicitly says 'PICK A TIER' and gives decision rules for standard vs best vs studio, including 'the right choice for almost every request' and 'only ... AFTER a standard job disappointed'. It makes clear this is the quoting step ('nothing trains until paid'), but does not explicitly mention sibling tools such as pay_training_job for the next step or get_training_job for status.

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.

Resources