Skip to main content
Glama

VAR2.ai

by ai.var2
OverviewDiscussionsAdmin

var2_create_dialog

TTS / voice-over (ElevenLabs v4 by default; model "elevenlabs-v3" for the previous generation, ≤5000 chars). dialogue = [{voice, text}, ...]. Default voices: EXAVITQu4vr4xnSDxMaL (Sarah, warm female), JBFqnCBsd6RMkjVDRZzb (George, warm British male). Hebrew: language_code "he" + nikud. Combined text ≤10000 chars. v4 reads English audio tags in square brackets inside text, before the words they color — [excited], [whispers], [sarcastic], [laughs], [sighs] — write them yourself, or pass auto_tag: true to have var2 add them. NOT for voice browsing — that's var2_get_voice_list.

Input Schema

NameRequiredDescriptionDefault
modelNoDialog model. Default elevenlabs-v4 (most expressive, ≤10000 chars). Only pass this when the user asks for a specific version.
titleNoOptional asset display name.
auto_tagNoElevenLabs v4 only. true = var2 adds fitting audio tags ([excited], [laughs]…) to every line before generating (free, limited per hour). Omit when you wrote the tags yourself.
dialogueYes
stabilityNo0 = expressive, 0.5 = balanced (default), 1 = monotone.
project_idNoOptional project to attach to. Defaults to the user's default project.
webhook_urlNoOptional. https:// URL var2 POSTs a signed delivery to when the asset is ready (or fails). Signature header: X-VAR2-Signature: t=<unix>, v1=<hex(hmac_sha256(webhook_secret, t + "." + body))>. Retried with exponential backoff (8 attempts over ~4 days).
language_codeNoISO 639-1 (e.g. "he"). Omit to auto-detect.
idempotency_keyNoOptional. Retries with the same key never double-bill (dedupes on ai_jobs.request_id). Use a stable per-user-action value (e.g. a UUID).
auto_tag_densityNoHow many tags auto_tag adds: light (≈1 per line), medium (default), rich.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / auto_tag
      Added value: +{
+  "description": "ElevenLabs v4 only. true = var2 adds fitting audio tags ([excited], [laughs]…) to every line before generating (free, limited per hour). Omit when you wrote the tags yourself.",
+  "type": "boolean"
+}
    • addedInput schema / properties / auto_tag_density
      Added value: +{
+  "description": "How many tags auto_tag adds: light (≈1 per line), medium (default), rich.",
+  "enum": [
+    "light",
+    "medium",
+    "rich"
+  ],
+  "type": "string"
+}
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations carry only a title, so the description bears nearly the full burden and does well: it discloses model defaults, per-model character ceilings, that auto_tag is 'free, limited per hour', tag placement semantics, and webhook signature/retry behavior via schema. The significant omission is that this is an asynchronous job — nothing tells the agent it must poll var2_get_dialog_result instead of expecting media back.

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?

Dense but front-loaded: purpose and payload shape lead, then defaults, then the sibling exclusion. One weak spot is that the opening '≤5000 chars' and the later 'Combined text ≤10000 chars' sit far apart and are easy to misread as conflicting, though no sentence is outright filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter, mutation-style tool with no output schema and title-only annotations, the description covers inputs, limits, limits-derived behavior, and locale handling thoroughly. It falls just short on the request lifecycle — it never says the work is queued and must be retrieved via var2_get_dialog_result, which is the one thing an agent needs to complete the flow.

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 already 90%, so the baseline is 3, and the description earns above that by contributing facts the schema lacks: the concrete default voice ids with human names (Sarah, George), the combined 10000-char budget across lines, and the semantics of where bracketed tags sit relative to words. Model, stability, and language_code semantics are left almost entirely to 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 states a specific verb and resource ('TTS / voice-over' creation) and immediately characterizes the payload shape ('dialogue = [{voice, text}, ...]'), so the agent knows this produces multi-speaker speech rather than a generic audio asset. It also actively differentiates itself from var2_get_voice_list ('NOT for voice browsing'), so it is distinguishable from at least one sibling without opening a schema.

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?

It gives clear context for use (dialogue voice-over, model selection, Hebrew handling, tag writing) and one explicit exclusion that routes voice discovery to var2_get_voice_list, plus tells the agent where voice ids come from. It does not, however, distinguish itself from the other audio-producing sibling var2_create_audio, leaving the agent to infer single-speaker vs dialogue.

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

All VAR2.ai toolsInspect
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.

Resources