Onepin

Build a standard workflow

create_workflow_from_intent

Build the ordinary workflow for the languages you name. The server draws it.

Prefer this over create_workflow: send the languages with their voices and ONE script route; the server decides the nodes, ports, translator and quality checks. Author a definition only for a shape this refuses. Call again with confirm=true.

Input Schema

Name	Required	Description
`name`	Yes	What the user will see it called. Its own question; never invented.
`force`	No	Skips the offer of an existing workflow. Only after the user chose to build a new one.
`checks`	No	Omit unless the user already named checks: "none" for none, or list them. Omitted builds the standard pair.
`speaks`	Yes	One entry per language the workflow speaks, each with its voice.
`confirm`	No	false creates nothing and returns what would be created. true creates it.
`normalize`	No	Omit to let the script decide, "standard" to normalize regardless, "none" to speak it as written.
`script_text`	No	Only a script the user typed into the conversation. A file goes through upload_script_file.
`audio_format`	No	The delivered audio format. Omit for the product default.
`source_language`	Yes	The locale the script is written in, e.g. 'en-us'.
`script_upload_id`	No	From finish_script_upload. The route for a file the user has.
`script_has_markup`	No	true when the script carries provider markup like <break/> the normalizer must keep.
`pronunciation_remediation`	No	Only if the user already asked: with a Pronunciation check, detect->correct->re-grade, not a retry.

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"
+  ]
+}
```

Changed11 schema fields changedOct 16, 2026

removedInput schema / properties / accept_defaults

Removed value: -{
-  "default": false,
-  "description": "Only after you put open_decisions to the user and they chose the defaults.",
-  "title": "Accept Defaults",
-  "type": "boolean"
-}

changedInput schema / properties / checks / description

Previous value: -"Omit or \"standard\" for the standard pair, \"none\" to build without any, or list the checks and their settings."New value: +"Omit unless the user already named checks: \"none\" for none, or list them. Omitted builds the standard pair."

changedInput schema / properties / name / description

Previous value: -"What the user will see it called. Ask them rather than inventing one."New value: +"What the user will see it called. Its own question; never invented."

changedInput schema / properties / normalize / description

Previous value: -"Omit to be asked, \"standard\" for the product's text normalizer, \"none\" to speak the script as written."New value: +"Omit to let the script decide, \"standard\" to normalize regardless, \"none\" to speak it as written."

changedInput schema / properties / pronunciation_remediation / description

Previous value: -"With a Pronunciation check listed, builds detect->correct->re-grade instead of a retry of the voice."New value: +"Only if the user already asked: with a Pronunciation check, detect->correct->re-grade, not a retry."

removedOutput schema / $defs / DecisionChoiceRow

Removed value: -{
-  "additionalProperties": true,
-  "properties": {
-    "description": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "display_name": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "node_type": {
-      "type": [
-        "string",
-        "null"
-      ]
-    }
-  },
-  "type": "object"
-}

addedOutput schema / $defs / FeatureChoiceRow

Added value: +{
+  "additionalProperties": true,
+  "properties": {
+    "already_present": {
+      "type": [
+        "boolean",
+        "null"
+      ]
+    },
+    "answer": {
+      "additionalProperties": true,
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "check": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "description": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "display_name": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "means": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "node_type": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

addedOutput schema / $defs / FeatureOfferRow

Added value: +{
+  "additionalProperties": true,
+  "properties": {
+    "ask": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "category": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "choices": {
+      "items": {
+        "$ref": "#/$defs/FeatureChoiceRow"
+      },
+      "type": [
+        "array",
+        "null"
+      ]
+    },
+    "if_skipped": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "label": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "selection": {
+      "type": [
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

removedOutput schema / $defs / OpenDecisionRow

Removed value: -{
-  "additionalProperties": true,
-  "properties": {
-    "ask": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "check": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "choices": {
-      "items": {
-        "$ref": "#/$defs/DecisionChoiceRow"
-      },
-      "type": [
-        "array",
-        "null"
-      ]
-    },
-    "decision": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "if_unanswered": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "options": {
-      "items": {
-        "additionalProperties": true,
-        "type": "object"
-      },
-      "type": [
-        "array",
-        "null"
-      ]
-    }
-  },
-  "type": "object"
-}

addedOutput schema / properties / feature_offers

Added value: +{
+  "items": {
+    "$ref": "#/$defs/FeatureOfferRow"
+  },
+  "type": [
+    "array",
+    "null"
+  ]
+}

removedOutput schema / properties / open_decisions

Removed value: -{
-  "items": {
-    "$ref": "#/$defs/OpenDecisionRow"
-  },
-  "type": [
-    "array",
-    "null"
-  ]
-}

First observedOct 14, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Beyond the annotations it discloses the most important behavioral trait: the server derives nodes, ports, translator and quality checks, so the caller should not pre-specify them, and confirm=false is a pure preview that creates nothing. That is real value over the structured hints. It stops short of warning that the tool is not idempotent — repeating confirm=true presumably builds a duplicate — and says nothing about failure modes or permissions.

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?

Three short sentences and a fragment, front-loaded with the action and the routing decision, with the confirm cycle last. Every sentence carries a distinct decision the agent must make; nothing is restated from the schema or annotations.

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 12-parameter, output-schema-backed creation tool, the description covers intent, the dry-run gate, and the alternative tool, which is what an agent needs to call it correctly. It leaves the roles of force, pronunciation_remediation, audio_format and script_has_markup entirely to the schema descriptions, which is acceptable but means the description alone is not a full briefing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is already high, but the description adds the conceptual constraint the schema cannot express: pass the languages with their voices and ONE script route, letting the server fill the rest. That reframes 12 parameters into a simple intent payload and tells the agent which of the many optional fields it should deliberately leave out.

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 gives a specific verb and resource ("Build the ordinary workflow") plus the decisive scope: it is driven by the languages the caller names and the server assembles the graph. It explicitly contrasts with the sibling create_workflow ("Prefer this over create_workflow ... Author a definition only for a shape this refuses"), so an agent can route between the two without reading either schema.

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

Usage Guidelines5/5

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

It states the when (you have languages + voices + one script route), the when-not (only author a definition for shapes this refuses), the named alternative (create_workflow), and even the calling sequence (first call shows what would be created, then call again with confirm=true). Nothing about tool selection is left to inference.

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?