Skip to main content
Glama

Clipform

by io.github.Clipform

Generate Text-to-Speech

clipform_generate_tts

Generate narration audio from text with word-level captions. Use this for quiz question narration, survey introductions, form instructions, or any node that benefits from a human voice. Proactively suggest narration for quizzes and content-rich forms - it significantly improves engagement.

Available voices: ryan (British male, clear), sonia (British female, warm), andrew (American male, smooth), ava (American female, vibrant), guy (American male, deep). Pick ONE voice that fits the topic - e.g. a London quiz gets ryan or sonia, a US sports quiz gets andrew or guy - and reuse that SAME voice for every item and every call across the whole form. Never mix voices within one form unless the user explicitly asks for multiple voices.

Use the tone parameter to direct HOW the voice speaks. Always set a tone that matches the form's mood - e.g. quizzes: "Energetic and playful, like a quiz show host teasing the audience", surveys: "Professional but warm, encouraging honest answers", personality quizzes: "Curious and reflective". This dramatically improves the narration quality.

Pass one item or many (max 10) - multiple items run in parallel. Returns audio URL and word-level captions per item.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemsYesOne or more TTS items to generate
contextYesDescribe the user's underlying goal in one sentence - not the tool you're calling.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultsYesOne result per item, in order

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed2 schema fields changed
    • addedOutput schema / properties / results / items / properties / captions / items / properties / words / minItems
      Added value: +1
    • changedOutput schema / properties / results / items / properties / captions / items / required
      Previous value: -[
-  "start",
-  "end",
-  "text"
-]New value: +[
+  "start",
+  "end",
+  "text",
+  "words"
+]
  2. Changed3 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / context
      Added value: +{
+  "description": "Describe the user's underlying goal in one sentence - not the tool you're calling.",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "items"
-]New value: +[
+  "items",
+  "context"
+]
  3. Changed1 schema field changed
    • changedInput schema / properties / items / items / properties / voice / description
      Previous value: -"Voice: ryan (British male, clear/articulate), sonia (British female, warm/bright), andrew (American male, smooth/neutral), ava (American female, vibrant/friendly), guy (American male, deep/authoritative). Pick based on the form's topic and audience."New value: +"Voice: ryan (British male, clear/articulate), sonia (British female, warm/bright), andrew (American male, smooth/neutral), ava (American female, vibrant/friendly), guy (American male, deep/authoritative). Pick ONE voice for the whole form based on its topic and audience, then reuse that same voice on every item and every call - never mix voices within a form unless the user explicitly asks for more than one."
  4. Changed1 schema field changed
    • changedOutput schema / properties / results / items / properties / captions / description
      Previous value: -"Pass as the captions param to upload_node_media"New value: +"Pass as the captions param to upload_media_asset"
  5. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "results": {
+      "description": "One result per item, in order",
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "audio_url": {
+            "type": "string"
+          },
+          "captions": {
+            "description": "Pass as the captions param to upload_node_media",
+            "items": {
+              "additionalProperties": false,
+              "properties": {
+                "end": {
+                  "type": "number"
+                },
+                "start": {
+                  "type": "number"
+                },
+                "text": {
+                  "type": "string"
+                },
+                "words": {
+                  "items": {
+                    "additionalProperties": false,
+                    "properties": {
+                      "end": {
+                        "type": "number"
+                      },
+                      "start": {
+                        "type": "number"
+                      },
+                      "word": {
+                        "type": "string"
+                      }
+                    },
+                    "required": [
+                      "word",
+                      "start",
+                      "end"
+                    ],
+                    "type": "object"
+                  },
+                  "type": "array"
+                }
+              },
+              "required": [
+                "start",
+                "end",
+                "text"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "error": {
+            "type": "string"
+          },
+          "ok": {
+            "type": "boolean"
+          }
+        },
+        "required": [
+          "ok"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "results"
+  ],
+  "type": "object"
+}
  6. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations only provide generic hint flags (readOnlyHint=false, idempotentHint=false), so the description carries the behavioral burden. It adds concrete details: accepts up to 10 items, runs multiple items in parallel, returns audio URLs and word-level captions, and mandates a single voice across the whole form. It does not cover side effects or rate limits, but nothing here contradicts the annotations.

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?

Every paragraph earns its place: purpose, use cases, voice selection, tone direction, and batch/return behavior. The most important decision rules (same voice for the whole form, tone matching) are given dedicated emphasis rather than buried.

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?

Given the output schema exists, the description need not re-explain return structure, but it still mentions the key output. It covers use cases, voice/tone selection rules, batch limits, and parallel behavior, making it complete for an agent to call and configure correctly.

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. The description adds real value beyond the schema by explaining voice personality choices (e.g., 'ryan British male, clear') and providing concrete tone examples for quizzes and surveys, plus the rule to reuse the same voice globally.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Generate narration audio from text with word-level captions', clearly identifying the verb, resource, and output. It lists concrete use cases like quiz question narration and survey introductions, but does not explicitly contrast it with sibling tools such as clipform_generate_video.

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?

Provides explicit when-to-use guidance ('Use this for quiz question narration, survey introductions...') and proactive recommendation to suggest narration for quizzes. It gives strong voice-consistency and tone-matching rules, but it does not mention when to prefer a different tool or state exclusions.

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

All Clipform toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.1/5.0
Disambiguation4/5

Most tools have clearly distinct purposes: form CRUD, node management, media upload/attach, rendering, search, and guidance retrieval are all separable. The main overlap is among the three render tools (clipform_generate_video, clipform_render_video_template, clipform_render_composition), but their descriptions include explicit disambiguation guidance, so an agent can correctly choose. clipform_get_guide and clipform_get_workflow are also similar but clearly differentiated.

Naming Consistency4/5

Tool names follow a consistent clipform_<verb>_<noun> pattern throughout, e.g., clipform_create_form, clipform_add_node, clipform_update_node, clipform_delete_node. Minor deviations exist: clipform_whoami is not verb_noun, and get_more_tools lacks the clipform_ prefix, but these are edge cases and the overall convention is highly predictable.

Tool Count3/5

34 tools is on the heavy side for a single MCP server. The server covers a broad domain (form creation, node editing, media management, video rendering, TTS, search, guidance, imports, responses), so the count is defensible, but it is above the typical well-scoped range and may add navigation overhead.

Completeness5/5

The tool surface covers the full lifecycle: create/read/update/delete forms and nodes, media upload/attach/delete, multiple render paths with status checking, TTS generation, music/image/video search, form import, response retrieval, and workflow/guide knowledge. The main gap is lack of a direct branching-logic editor (option-based branching is only in the dashboard), but the API consciously documents that limitation and the rest of the lifecycle is complete.

Resources