Skip to main content
Glama
aashuchahal4-crypto

creatoros-mcp

by aashuchahal4-crypto
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

creatoros_speak

Converts English text into voiceover-ready speech audio with human inflection and cadence, returning a playable URL or stream for podcasts, narration, and spoken responses.

Instructions

Converts English text into natural, studio-quality speech audio with human inflection and cadence using the CreatorOS Neural Voice Studio. Returns a playable audio URL or audio stream.

When to use:

  • Use when the user requests spoken voice responses, podcast narration, voiceover scripts, or audio synthesis of text.

When NOT to use:

  • Do not use for text extraction, web scraping, or non-audio tasks.

Behavior:

  • Synthesizes neural audio on demand. Free tier supports up to 250 characters per generation; Pro Pass supports up to 5,000 characters.

Input Schema

NameRequiredDescriptionDefault
textYesThe English script to convert into voice audio (up to 250 characters free, 5000 characters with Pro Pass).
voiceNoThe voice persona to use: "anna" (warm female), "charles" (deep male), "alba" (bright male), or "stuart_bell" (documentary narrator). Default is "anna".anna

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.0.1
    • changedInput schema / properties / text / description
      Previous value: -"The English text script to convert into voice audio (up to 250 characters free, 5000 characters with Pro Pass)."New value: +"The English script to convert into voice audio (up to 250 characters free, 5000 characters with Pro Pass)."
    • addedInput schema / properties / text / maxLength
      Added value: +5000
    • addedInput schema / properties / text / minLength
      Added value: +1
    • addedInput schema / properties / voice / default
      Added value: +"anna"
    • changedInput schema / properties / voice / description
      Previous value: -"Voice persona: \"anna\" (warm female), \"charles\" (deep male), \"alba\" (bright male), \"stuart_bell\" (narrator). Default is \"anna\"."New value: +"The voice persona to use: \"anna\" (warm female), \"charles\" (deep male), \"alba\" (bright male), or \"stuart_bell\" (documentary narrator). Default is \"anna\"."
    • addedInput schema / properties / voice / enum
      Added value: +[
+  "anna",
+  "charles",
+  "alba",
+  "stuart_bell"
+]
  2. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does disclose the key operational constraint: 250 characters on free tier versus 5,000 with Pro Pass, plus what the call returns. It does not cover latency, failure behavior when the character limit is exceeded, or how long the generated audio is retained.

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?

Clearly front-loaded with the core action, then structured into when/when-not/behavior blocks that are easy to scan. Slight redundancy in repeating the character limits already stated in the schema keeps it off a 5.

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 simple two-parameter synthesis tool with no output schema, the description covers purpose, the return value, and the tier-based input ceiling, which is enough to call it correctly. Edge cases like what happens on exceeding the limit or unsupported language are unaddressed.

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 description coverage is 100%, so both 'text' and 'voice' are already fully documented, including the enum persona meanings and the default. The description's character-limit note merely restates what the schema field already says, adding no new parameter guidance; baseline 3 applies.

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 precise verb+resource: converting English text into speech audio via a named engine, and adds the return shape (playable audio URL or audio stream). The 'when NOT to use' clause (no text extraction, no web scraping) carves it away from the sibling tools creatoros_extract and creatoros_search.

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?

Explicitly enumerates when to invoke it (spoken responses, podcast narration, voiceover, audio synthesis) and when not to, which routes the agent away from the non-audio siblings. The only thing left implicit is naming the siblings outright, but their domains are covered.

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

Deploy Server

Other Tools