Onepin

Build an audio workflow

create_audio_workflow_from_intent

Build a workflow around audio the user already has. The server draws it.

Give the uploaded clips with their languages; source_audio is wired to an Export, no voice or generator. Name checks to score it — a check drops its failed clips unless you wire its fail to an Export on the canvas. Call again with confirm=true.

Input Schema

Name	Required	Description
`name`	Yes	What the user will see it called. Ask them rather than inventing one.
`checks`	No	Omit to be offered them, "none" for none, "standard" for the pair, or list them.
`confirm`	No	false creates nothing and returns what would be created. true creates it.
`audio_format`	No	The delivered audio format. Omit for the product default.
`audio_inputs`	Yes	One entry per uploaded clip, each with the language it is in and — only for a Word Accuracy or Pronunciation check — its script.
`default_language`	No	A fallback locale for lines that omit one, e.g. 'en-us'. Every line still needs one.

Output Schema

Name	Required	Description	Default
`name`	No
`nodes`	No
`valid`	No
`errors`	No
`blocked`	No
`created`	No
`next_step`	No
`console_url`	No
`workflow_id`	No
`not_included`	No
`feature_offers`	No
`workspace_slug`	No
`workflow_summary`	No
`requires_confirmation`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 23, 2026

changedInput schema / $defs / Precede / description

Previous value: -"Put a node immediately in front of this check, on the path it grades."New value: +"Settings for the Phoneme Injector this check is always built with."

changedInput schema / $defs / Precede / properties / with / description

Previous value: -"The node placed immediately before this check. Its wiring is the server's."New value: +"The node those settings are for. It is added either way."

Changed1 schema field changedOct 19, 2026
- addedOutput schema / $defs / FeatureChoiceRow / properties / applies_to_locales
```
Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": [
+    "array",
+    "null"
+  ]
+}
```
AddedOct 16, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover the safety profile (non-destructive write, closed world, non-idempotent). The description adds useful behavior beyond that: the server draws the graph, source_audio is wired to an Export with no voice/generator, checks drop failed clips unless their fail is wired to an Export, and confirm=false creates nothing. It does not discuss permissions or limits, but is strong for an annotated tool.

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?

Every sentence carries operational information, and the core instruction is front-loaded. Some phrasing is terse to the point of ambiguity ('Name checks to score it'), but there is no padding.

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?

Given the existing output schema and rich parameter descriptions, the description covers the critical workflow: use uploaded clips, source_audio is wired to Export, checks drop failed clips unless fail is wired to Export, and confirm=true commits. Minor gaps remain around omitted checks behavior and explicit prerequisites, but nothing essential for correct invocation is missing.

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%, so the baseline is 3. The description still adds practical meaning: it tells the agent to supply uploaded clips with languages, how checks should be named, and that a check's fail routing matters ('a check drops its failed clips unless you wire its fail to an Export'), which goes beyond the raw on_fail 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?

States a specific verb and resource: build a workflow around audio the user already has. The phrases 'source_audio is wired to an Export, no voice or generator' distinguish it from script-based workflow creation siblings. An agent can tell this is the bring-your-own-audio path without opening another 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?

Gives clear prerequisites ('Give the uploaded clips with their languages') and an explicit two-step pattern ('Call again with confirm=true'). It does not name an alternative sibling such as create_workflow_from_intent or explicitly say when not to use this tool, so it falls short of full when/when-not guidance.

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

All Onepin tools Inspect

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

Need Help?