Skip to main content
Glama
marswaveai

ListenHub MCP Server

by marswaveai
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
TypeScript
Remote

Official MCP Server for ListenHub, supporting AI podcast generation (single or dual-speaker), FlowSpeech creation, and more. Available for ListenHub Pro plan and above.

Quick Start

Environment Configuration

Installing Node.js

This server requires Node.js version 18 or higher. If you haven't installed Node.js yet, please follow the instructions below:

  • macOS Method 1: Using Official Installer

    1. Visit the Node.js official website and download the Node.js Long Term Support version, such as v24.11.0(LTS)

    2. Open the downloaded .pkg file and follow the installation wizard

    3. Open Terminal and run the following commands to verify installation:

    node --version
npm --version

    Method 2: Using Homebrew If you don't have Homebrew installed, use the following script to install it:

    /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
    # After successful installation, use brew to download Node.js
brew install node

    Then verify the installation:

    node --version
npm --version

  • Windows Method 1: Using Official Installer

    1. Visit the Node.js official website

    2. Download the LTS (Long Term Support) version for Windows

    3. Run the downloaded .msi installer

    4. Follow the installation wizard

    5. Open PowerShell and run the following commands to verify installation:

    node --version
npm --version

    Method 2: Using winget (Windows Package Manager) If you're using Windows 10 version 1809 or higher:

    winget install OpenJS.NodeJS.LTS

    Then verify the installation:

    node --version
npm --version

    Method 3: Using Chocolatey If you have Chocolatey installed:

    choco install nodejs-lts

    Then verify the installation:

    node --version
npm --version

  • Linux Ubuntu/Debian

    # Install Node.js 20.x (LTS)
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash -
sudo apt-get install -y nodejs

    Fedora/RHEL/CentOS

    # Install Node.js 20.x (LTS)
curl -fsSL https://rpm.nodesource.com/setup_20.x | sudo bash -
sudo yum install -y nodejs

    Verify the installation:

    node --version
npm --version

Get ListenHub API Key

Get your API key from the ListenHub API Keys Settings page and use it as the value for the LISTENHUB_API_KEY environment variable.

Configuration Methods for Each Client

  • Claude Desktop Edit your Claude Desktop configuration file: macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%\Claude\claude_desktop_config.json Add the following configuration:

    {
  "mcpServers": {
    "listenhub": {
      "command": "npx",
      "args": ["-y", "@marswave/listenhub-mcp-server@latest"],
      "env": {
        "LISTENHUB_API_KEY": "your_api_key_here"
      }
    }
  }
}

    Replace your_api_key_here with your actual API key obtained from ListenHub.

  • Cursor

    1. Open Cursor Settings

    2. Navigate to Features → Model Context Protocol

    3. Click Add MCP Server or directly edit the configuration file Configuration file location:

    • macOS/Linux: ~/.cursor/mcp.json

    • Windows: %APPDATA%\Cursor\mcp.json Add the following configuration:

    {
  "mcpServers": {
    "listenhub": {
      "command": "npx",
      "args": ["-y", "@marswave/listenhub-mcp-server@latest"],
      "env": {
        "LISTENHUB_API_KEY": "your_api_key_here"
      }
    }
  }
}

    Replace your_api_key_here with your actual API key obtained from ListenHub. Optional: HTTP Mode To use HTTP transport, manually start the server:

    export LISTENHUB_API_KEY="your_api_key_here"
npx @marswave/listenhub-mcp-server --transport http --port 3000

    Then configure Cursor:

    {
  "mcpServers": {
    "listenhub": {
      "url": "http://localhost:3000/mcp"
    }
  }
}

  • Windsurf

    1. Open Windsurf Settings

    2. Navigate to the MCP Servers section

    3. Add new server configuration Configuration file location:

    • macOS/Linux: ~/.windsurf/mcp_server_config.json

    • Windows: %APPDATA%\Windsurf\mcp_server_config.json Add the following configuration:

    {
  "mcpServers": {
    "listenhub": {
      "command": "npx",
      "args": ["-y", "@marswave/listenhub-mcp-server@latest"],
      "env": {
        "LISTENHUB_API_KEY": "your_api_key_here"
      }
    }
  }
}

    Replace your_api_key_here with your actual API key obtained from ListenHub.

  • VS Code (via Cline Extension)

    1. Install the Cline Extension from VS Code Marketplace

    2. Open VS Code Settings

    3. Search for "Cline: MCP Settings"

    4. Click "Edit in settings.json" Add the following configuration:

    {
  "cline.mcpServers": {
    "listenhub": {
      "command": "npx",
      "args": ["-y", "@marswave/listenhub-mcp-server@latest"],
      "env": {
        "LISTENHUB_API_KEY": "your_api_key_here"
      }
    }
  }
}

    Replace your_api_key_here with your actual API key obtained from ListenHub.

  • Zed Editor

    1. Open Zed Settings

    2. Navigate to the MCP section

    3. Edit the configuration file Configuration file location:

    • macOS/Linux: ~/.config/zed/mcp.json

    • Windows: %APPDATA%\Zed\mcp.json Add the following configuration:

    {
  "mcpServers": {
    "listenhub": {
      "command": "npx",
      "args": ["-y", "@marswave/listenhub-mcp-server@latest"],
      "env": {
        "LISTENHUB_API_KEY": "your_api_key_here"
      }
    }
  }
}

    Replace your_api_key_here with your actual API key obtained from ListenHub.

  • Claude CLI Run the following command in your terminal:

    claude mcp add listenhub --env LISTENHUB_API_KEY=<insert-your-api-key-here> -- npx -y @marswave/listenhub-mcp-server

    Replace <insert-your-api-key-here> with your actual API key obtained from ListenHub.

  • Codex CLI Run the following command in your terminal:

    codex mcp add listenhub --env LISTENHUB_API_KEY=<insert-your-api-key-here> -- npx -y @marswave/listenhub-mcp-server

    Replace <insert-your-api-key-here> with your actual API key obtained from ListenHub.

  • ChatWise

    1. Open ChatWise Settings, select MCP, click "+" to add a new MCP service

    2. Fill in the following information in the MCP configuration module:

      • Command: npx -y @marswave/listenhub-mcp-server@latest

      • Environment Variables: Add LISTENHUB_API_KEY with your API key as the value

    3. Enable the tool below the chat input box to start using it

  • Other MCP Clients For other MCP-compatible clients, use the standard MCP configuration format:

    {
  "mcpServers": {
    "listenhub": {
      "command": "npx",
      "args": ["-y", "@marswave/listenhub-mcp-server@latest"],
      "env": {
        "LISTENHUB_API_KEY": "your_api_key_here"
      }
    }
  }
}

    Replace your_api_key_here with your actual API key obtained from ListenHub.

Related MCP server: MCP Server Whisper

Usage Examples

Generate English Podcast

image.png

Core Features

  • Podcast Generation:

    • Support for full generation (text + audio) or text-only generation

    • Support for 1-2 speakers with customizable voices

    • Multiple generation modes: Quick Listen, Deep Exploration, Debate

    • Support for two-stage generation

    • Support for text and URL content sources

    • Query podcast generation status

    • Access audio files, titles, scripts, and outlines

    • Track credit consumption

  • FlowSpeech Voice Generation:

    • Convert written content from text or URLs into single-speaker conversational audio

    • Support for Smart mode (AI-enhanced reading) or Direct mode (verbatim reading)

    • Query FlowSpeech generation status

    • Access audio files, titles, scripts, and outlines

    • Track credit consumption

  • Speaker Management:

    • Browse available speakers/voice library

    • Filter by language and speaker attributes

    • Get speaker ID, name, language, gender, and demo audio

  • User Account Management:

    • Query subscription status and plan information

    • View credit usage: monthly credits, permanent credits, and limited-time credits

    • Monitor total available credits and renewal status

    • View subscription start/expiration dates

  • Multiple Transport Modes: Support for Stdio, HTTP SSE, and HTTP Streamable transport methods for flexible integration

Transport Modes

The server supports multiple transport modes to suit different use cases.

Stdio Mode (Default)

Standard input/output communication. This is the default mode used by most MCP clients (such as Claude Desktop, Cursor, etc.).

All configuration examples above use stdio mode by default, requiring no additional setup.

HTTP/SSE Mode

For advanced use cases, you can run the server in HTTP mode, providing both HTTP streaming and Server-Sent Events (SSE) endpoints.

Start the server in HTTP mode:

# macOS/Linux
export LISTENHUB_API_KEY="your_api_key_here"
npx @marswave/listenhub-mcp-server --transport http --port 3000
# Windows
set LISTENHUB_API_KEY=your_api_key_here

npx @marswave/listenhub-mcp-server --transport http --port 3000

Available endpoints:

  • HTTP Streaming: http://localhost:3000/mcp

  • Server-Sent Events: http://localhost:3000/sse

Configure your MCP client to use HTTP endpoint:

{
  "mcpServers": {
    "listenhub": {
      "url": "http://localhost:3000/mcp"
    }
  }
}

Available Tools

Speaker Query

  • get_speakers - Get a list of available speakers for podcast generation. Returns speaker ID, name, language, gender, and demo audio link.

    • language: Filter by language code (zh/en) (string, optional)

Podcast Generation

  • create_podcast - Create a podcast with full generation (text + audio). Supports 1-2 speakers. Automatically polls until completion (may take several minutes).

    • query: Content or topic (string, optional)

    • sources: Array of text/URL sources (array, optional)

    • speakerIds: Array of 1-2 speaker IDs (array, required)

    • language: Language code - zh or en (string, optional, default: en)

    • mode: Generation mode - quick, deep, or debate (string, optional, default: quick)

  • get_podcast_status - Query detailed information about a podcast. Returns current status immediately without polling.

    • episodeId: Podcast ID (string, required)

  • create_podcast_text_only - Create a podcast with text content only (no audio). First stage of two-stage generation.

    • query: Content or topic (string, optional)

    • sources: Array of text/URL sources (array, optional)

    • speakerIds: Array of 1-2 speaker IDs (array, required)

    • language: Language code - zh or en (string, required)

    • mode: Generation mode - quick, deep, or debate (string, optional, default: quick)

    • waitForCompletion: Wait for generation to complete (boolean, optional, default: true)

  • generate_podcast_audio - Generate audio for a podcast with existing text content. Second stage of two-stage generation.

    • episodeId: Podcast ID (string, required)

    • customScripts: Array of custom scripts (array, optional)

    • waitForCompletion: Wait for generation to complete (boolean, optional, default: true)

FlowSpeech Generation

  • create_flowspeech - Convert text or URL content to speech, creating FlowSpeech. Supports Smart mode (AI-enhanced) and Direct mode (no modifications).

    • sourceType: Source type - text or url (string, required)

    • sourceContent: Source content (text or URL) (string, required)

    • speakerId: Speaker ID for narration (string, required)

    • language: Language code - zh or en (string, optional)

    • mode: Generation mode - smart or direct (string, optional, default: smart)

  • get_flowspeech_status - Query detailed information about FlowSpeech. Returns current status immediately without polling.

    • episodeId: FlowSpeech ID (string, required)

User Account Query

  • get_user_subscription - Get current user's subscription information, including subscription status, credit usage, plan details, and renewal status.

Thank you for using ListenHub MCP Server!

If you have any questions, please feel free to contact us: support@marswave.ai

Available Tools

8 tools
create_flowspeechA

Create a FlowSpeech episode by converting text or URL content to speech. Supports smart mode (AI-enhanced, fixes grammar) and direct mode (no modifications). This tool will automatically poll until generation is complete.

ParametersJSON Schema
NameRequiredDescriptionDefault
sourceTypeYesSource type: text or url
sourceContentYesSource content (text or URL)
speakerIdYesSpeaker name or ID. Use speaker name from get_speakers tool output (the "name" field, not speakerId). Full speaker ID also supported.
languageNoLanguage code (e.g., "zh" for Chinese, "en" for English). Default: zh
modeNoGeneration mode: "smart" (AI-enhanced, fixes grammar) or "direct" (no modifications)smart

TDQS

A4.2/5.0
Behavior4/5

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

The description adds valuable behavioral context beyond annotations: it reveals that the tool 'automatically polls until generation is complete' (asynchronous behavior) and explains the difference between smart mode (AI-enhanced with grammar fixes) and direct mode (no modifications). While annotations provide readOnlyHint=false and openWorldHint=true, the description adds practical implementation details that help the agent understand runtime behavior.

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?

The description is perfectly front-loaded with the core purpose in the first sentence, followed by mode explanations and behavioral detail. Every sentence earns its place by providing essential information without redundancy. The three-sentence structure is efficient and well-organized.

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 creation tool with no output schema, the description provides good context about what the tool does and its behavioral characteristics. It covers the creation process, mode differences, and polling behavior. However, it doesn't mention what the tool returns (e.g., episode ID, status object) or error conditions, which would be helpful given the absence of an output schema.

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?

With 100% schema description coverage, the input schema already documents all 5 parameters thoroughly. The description mentions 'smart mode (AI-enhanced, fixes grammar) and direct mode (no modifications)' which slightly elaborates on the mode parameter, but doesn't add significant semantic value beyond what's already in the schema descriptions. This meets the baseline expectation for high schema coverage.

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 clearly states the specific action ('Create a FlowSpeech episode'), the resource involved ('by converting text or URL content to speech'), and distinguishes it from siblings by focusing on FlowSpeech rather than podcast-related tools. It provides a precise verb+resource combination that leaves no ambiguity about the tool's function.

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?

The description provides clear context about when to use this tool (converting text/URL to speech) and mentions two modes (smart vs direct) which gives operational guidance. However, it doesn't explicitly state when to choose this tool over sibling tools like create_podcast or generate_podcast_audio, nor does it mention any prerequisites or exclusions.

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

create_podcastA

Create a podcast episode with full generation (text + audio). Supports single-speaker (solo) or dual-speaker (dialogue) formats with 1-2 speakers (can use speaker names or IDs). Choose from 3 generation modes: quick (3-5 min podcast), deep (8-15 min podcast), or debate (5-10 min podcast). Accepts text or URL sources. This tool will automatically poll until generation is complete (may take several minutes).

ParametersJSON Schema
NameRequiredDescriptionDefault
queryNoThe content or topic for the podcast (optional if sources provided)
sourcesNoAdditional sources (text or URLs)
speakersYes1-2 speaker names or IDs. Use speaker names from get_speakers tool output (the "name" field, not speakerId). Full speaker IDs also supported. Names will be automatically resolved to IDs.
languageNoLanguage code (e.g., "zh" for Chinese, "en" for English). Should match the selected speaker's language. If not specified, will use the first speaker's language.
modeNoGeneration mode (time indicates podcast audio length): "quick" (3-5 min audio): Fast-paced content for simple topics, news summaries, brief introductions. Supports 1-2 speakers. "deep" (8-15 min audio): Comprehensive analysis for detailed topics, in-depth explanations, thorough coverage. Supports 1-2 speakers. "debate" (5-10 min audio): Conversational discussion, interviews, dialogues, debates, Q&A sessions. Supports 1-2 speakers. Default: quickquick

TDQS

A4.2/5.0
Behavior4/5

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

Annotations indicate this is a write operation (readOnlyHint: false) and supports open-world data (openWorldHint: true). The description adds valuable behavioral context beyond annotations by specifying that the tool automatically polls until generation is complete (which may take several minutes), disclosing the time-consuming nature of the operation.

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?

The description is efficiently structured in three sentences: first covers purpose and formats, second details generation modes and inputs, third explains the polling behavior. Every sentence provides essential information with zero wasted words, making it highly front-loaded and concise.

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 complex tool with 5 parameters, no output schema, and annotations covering basic safety, the description does well by explaining generation modes, polling behavior, and speaker resolution. However, it doesn't describe the return value or error conditions, leaving some gaps in completeness for a tool that performs a potentially lengthy operation.

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?

With 100% schema description coverage, the schema already documents all 5 parameters thoroughly. The description adds minimal additional semantic context, such as clarifying that speakers can be names or IDs and that names are resolved automatically, but this is largely redundant with the schema. Baseline 3 is appropriate given the comprehensive 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 clearly states the tool creates a podcast episode with full generation (text + audio), specifies supported formats (single-speaker or dual-speaker), and distinguishes it from siblings like create_podcast_text_only and generate_podcast_audio by emphasizing the comprehensive nature of the generation.

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?

The description provides clear context on when to use this tool by detailing generation modes (quick, deep, debate) and input options (text or URL sources). However, it doesn't explicitly mention when to choose this over alternatives like create_podcast_text_only or generate_podcast_audio, which would be needed for a perfect score.

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

create_podcast_text_onlyA

Create podcast episode with text content only (no audio generation). Supports single-speaker (solo) or dual-speaker (dialogue) formats with 1-2 speakers (can use speaker names or IDs). Choose from 3 generation modes: quick (3-5 min podcast), deep (8-15 min podcast), or debate (5-10 min podcast). This is the first stage of two-stage generation. After text generation completes, you can review the scripts. To use modified scripts, call generate_podcast_audio with customScripts parameter to override the generated scripts when generating audio.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryNoThe content or topic for the podcast (optional if sources provided)
sourcesNoAdditional sources (text or URLs)
speakerIdsYes1-2 speaker names or IDs. Use speaker names from get_speakers tool output (the "name" field, not speakerId). Full speaker IDs also supported.
languageYesLanguage code (e.g., "zh" for Chinese, "en" for English). Must match the selected speaker's language - REQUIRED
modeNoGeneration mode (time indicates podcast audio length): "quick" (3-5 min audio): Fast-paced content for simple topics, news summaries, brief introductions. Supports 1-2 speakers. "deep" (8-15 min audio): Comprehensive analysis for detailed topics, in-depth explanations, thorough coverage. Supports 1-2 speakers. "debate" (5-10 min audio): Conversational discussion, interviews, dialogues, debates, Q&A sessions. Supports 1-2 speakers. Default: quickquick
waitForCompletionNoWhether to wait for text generation to complete

TDQS

A4.3/5.0
Behavior4/5

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

The description adds valuable behavioral context beyond annotations: it explains this is a two-stage process, mentions review capability for generated scripts, and describes the three generation modes with their time ranges and use cases. While annotations provide readOnlyHint=false and openWorldHint=true, the description adds workflow-specific behavior. No contradiction with annotations.

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?

The description is appropriately sized and front-loaded with the core purpose. Every sentence adds value: first sentence states purpose and constraints, second explains speaker formats, third explains generation modes, fourth explains two-stage workflow, fifth explains review capability, sixth explains alternative tool usage. Could be slightly more concise but all content is relevant.

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 tool's complexity (6 parameters, no output schema, read/write operation), the description provides good context about the workflow, generation modes, and relationship to other tools. It explains the two-stage process and how to proceed to audio generation. The main gap is lack of information about return values or what the generated text output looks like.

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?

With 100% schema description coverage, the baseline is 3. The description doesn't add significant parameter semantics beyond what's already in the schema descriptions, though it does mention speaker names/IDs and generation modes which are covered in the schema. The description provides context about the overall tool but minimal additional parameter-specific information.

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 clearly states the tool creates a podcast episode with text content only, specifies it's text-only (no audio generation), and distinguishes it from sibling tools by mentioning it's the first stage of two-stage generation and that generate_podcast_audio is used for audio. It provides specific details about speaker formats (solo/dialogue with 1-2 speakers) and generation modes (quick/deep/debate).

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?

The description explicitly states when to use this tool vs alternatives: 'This is the first stage of two-stage generation' and 'After text generation completes, you can review the scripts. To use modified scripts, call generate_podcast_audio with customScripts parameter to override the generated scripts when generating audio.' It provides clear workflow guidance and distinguishes from audio generation tools.

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

generate_podcast_audioA

Generate audio for a podcast episode that already has text content. This is the second stage of two-stage generation. The episode must have contentStatus=text-success. You can optionally provide customScripts parameter to override the generated scripts when generating audio. NOTE: This is the ONLY way to use modified scripts - there is no separate tool to edit scripts after generation.

ParametersJSON Schema
NameRequiredDescriptionDefault
episodeIdYesThe complete 24-character episode ID from the previous create_podcast_text_only response. IMPORTANT: Must be exactly 24 characters. Copy the FULL Episode ID - do not truncate or shorten it.
customScriptsNoOptional custom scripts to override generated ones
waitForCompletionNoWhether to wait for audio generation to complete

TDQS

A4.4/5.0
Behavior4/5

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

The description adds valuable behavioral context beyond annotations. Annotations indicate readOnlyHint=false (mutation) and openWorldHint=true (idempotent/retry-safe), but the description adds that this is a 'second stage' process with a prerequisite (contentStatus=text-success) and clarifies the customScripts override mechanism. It doesn't mention rate limits, auth needs, or destructive effects, but given the annotations cover the safety profile, the added context is sufficient for a high score.

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?

The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by essential context (two-stage process, prerequisite), and ends with a critical note about customScripts. Every sentence earns its place with no redundant information, making it highly efficient.

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 tool's complexity (multi-stage workflow with prerequisites) and lack of output schema, the description is mostly complete. It explains the tool's role in the workflow, prerequisites, and key behavioral notes. However, it doesn't describe the return value or what happens after audio generation (e.g., status updates, error handling), which is a minor gap given no output schema exists.

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 the schema already fully documents all parameters. The description adds minimal parameter semantics: it mentions customScripts as optional for overriding generated scripts, but doesn't provide additional meaning beyond what's in the schema. This meets the baseline of 3 when schema coverage is high.

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 clearly states the tool's purpose: 'Generate audio for a podcast episode that already has text content.' It specifies this is the 'second stage of two-stage generation' and distinguishes it from sibling tools like create_podcast_text_only (first stage) and create_podcast (which appears to be a combined tool). The verb 'generate' and resource 'audio for a podcast episode' are specific and unambiguous.

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?

The description provides explicit usage guidelines: it states when to use this tool ('episode must have contentStatus=text-success'), when not to use it (implied: not for initial text creation), and alternatives (create_podcast_text_only for first stage). It also clarifies that 'This is the ONLY way to use modified scripts - there is no separate tool to edit scripts after generation,' which helps avoid incorrect tool selection.

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

get_flowspeech_statusA
Read-only

Query detailed information of a FlowSpeech episode, including generation status, audio URLs, scripts, outline, and metadata. Does not poll - returns current status immediately.

ParametersJSON Schema
NameRequiredDescriptionDefault
episodeIdYesThe FlowSpeech episode ID

TDQS

A4.2/5.0
Behavior4/5

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

The description adds valuable behavioral context beyond what annotations provide. While annotations already declare readOnlyHint=true and openWorldHint=true, the description specifies that it 'returns current status immediately' and 'Does not poll', which are important operational characteristics not captured in annotations. No contradictions with annotations exist.

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?

The description is perfectly concise with two sentences that each earn their place. The first sentence states the purpose and scope, while the second provides crucial behavioral guidance about immediate return without polling. No wasted words or redundancy.

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 read-only query tool with good annotations and a simple single-parameter schema, the description provides adequate context about what information is returned and the immediate nature of the response. However, without an output schema, the description could benefit from more detail about the structure of returned data (though it lists data categories).

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?

With 100% schema description coverage, the input schema already fully documents the single 'episodeId' parameter. The description doesn't add any additional parameter semantics beyond what's in the schema, so it meets the baseline expectation without providing extra value.

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 clearly states the specific action ('Query detailed information') and resource ('a FlowSpeech episode'), listing the exact data returned (generation status, audio URLs, scripts, outline, metadata). It distinguishes from sibling tools like 'create_flowspeech' or 'get_podcast_status' by focusing on FlowSpeech episodes specifically.

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?

The description provides clear context for when to use this tool ('Does not poll - returns current status immediately'), which helps differentiate it from potential polling alternatives. However, it doesn't explicitly mention when not to use it or name specific alternatives among the sibling tools.

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

get_podcast_statusA
Read-only

Query detailed information of a podcast episode, including generation status, audio URLs, scripts, outline, and metadata. Does not poll - returns current status immediately.

ParametersJSON Schema
NameRequiredDescriptionDefault
episodeIdYesThe complete 24-character episode ID. IMPORTANT: Must be exactly 24 characters. Copy the FULL Episode ID from the Episode ID field in the previous response.

TDQS

A4.4/5.0
Behavior4/5

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

The annotations already provide readOnlyHint=true and openWorldHint=true, indicating this is a safe read operation that may return partial data. The description adds valuable behavioral context beyond annotations by specifying that it 'returns current status immediately' (non-polling behavior) and listing the specific types of information returned (generation status, audio URLs, scripts, outline, metadata), which helps the agent understand what to expect from the response.

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?

The description is perfectly concise with two sentences that each serve distinct purposes: the first explains what the tool does and what information it returns, the second clarifies important behavioral characteristics. There is zero wasted language or redundancy.

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 tool has good annotations (readOnlyHint, openWorldHint) and a well-documented single parameter, the description provides excellent context about what information is returned and the immediate (non-polling) behavior. The main gap is the lack of output schema, but the description compensates well by listing the specific data elements returned. For a read-only status check tool, this is quite complete.

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%, with the parameter fully documented in the schema (episodeId with format constraints and usage instructions). The description doesn't add any parameter-specific information beyond what's already in the schema, so it meets the baseline expectation without adding extra value.

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 clearly states the specific action ('Query detailed information') and resource ('podcast episode'), with explicit details about what information is included (generation status, audio URLs, scripts, outline, metadata). It distinguishes from siblings by specifying it returns current status immediately rather than polling, unlike potentially similar status-checking tools.

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?

The description explicitly states when to use this tool ('Does not poll - returns current status immediately'), providing clear guidance on its behavior versus alternatives that might involve polling. This helps the agent understand this is for immediate status checks rather than continuous monitoring.

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

get_speakersA
Read-only

Get list of available published speakers for podcast generation. Supports filtering by language code (e.g. "zh", "en"). Returns speaker ID, name, language, gender and demo audio URL. Defaults to Chinese speakers if no language specified.

ParametersJSON Schema
NameRequiredDescriptionDefault
languageNoFilter by language code (e.g. "zh" for Chinese, "en" for English). Default: zhzh

TDQS

A4.2/5.0
Behavior4/5

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

Annotations indicate readOnlyHint=true and openWorldHint=true, which the description aligns with by describing a retrieval operation. The description adds valuable context beyond annotations: it specifies that speakers are 'published' and 'available,' mentions the default language behavior, and lists the return fields (speaker ID, name, language, gender, demo audio URL). This enhances understanding of what the tool provides without contradicting 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?

The description is efficiently structured in two sentences: the first states the purpose and filtering capability, the second details the return fields and default behavior. Every sentence adds value without redundancy, making it front-loaded and easy to parse for an AI agent.

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 tool's low complexity (1 optional parameter) and rich annotations (readOnlyHint, openWorldHint), the description is mostly complete. It covers purpose, usage, and output details, though there's no output schema. It could improve by mentioning potential limitations like pagination or error cases, but overall it provides sufficient context for effective tool selection and invocation.

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?

The input schema has 100% description coverage, with the 'language' parameter fully documented in the schema. The description adds minimal semantics beyond the schema by reiterating filtering by language code and providing examples ('zh', 'en'), but doesn't introduce new parameter insights. With high schema coverage, a baseline score of 3 is appropriate as the description doesn't significantly enhance parameter understanding.

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 clearly states the tool's purpose: 'Get list of available published speakers for podcast generation.' It specifies the resource (speakers), the action (get list), and the context (podcast generation). It distinguishes from sibling tools like create_podcast or get_podcast_status by focusing specifically on speaker retrieval rather than podcast creation or status checking.

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?

The description provides clear context for when to use this tool: for obtaining speakers for podcast generation. It mentions filtering by language code and defaults to Chinese if unspecified, which helps guide usage. However, it doesn't explicitly state when NOT to use it or name alternatives among siblings, such as whether other tools might provide speaker information differently.

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

get_user_subscriptionA
Read-only

Get current user subscription information, including subscription status, credit usage, plan details, and renewal status.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation with potentially incomplete data. The description adds value by specifying the types of information returned (status, credit usage, etc.), which helps the agent understand what to expect beyond just 'subscription data'. It doesn't disclose rate limits, auth needs, or data freshness, but with annotations covering key safety aspects, this is adequate.

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?

The description is a single, efficient sentence that front-loads the core action ('Get current user subscription information') and follows with specific details. Every word adds value by clarifying the data scope, with no redundant or vague phrasing. It's appropriately sized for a no-parameter read tool.

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

Completeness3/5

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

Given the tool's simplicity (0 parameters, read-only, no output schema), the description is reasonably complete for its purpose. It specifies what data is returned, which compensates for the lack of output schema. However, it doesn't address potential complexities like error cases, authentication requirements, or data format, leaving some gaps for the agent.

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?

The tool has 0 parameters, and schema description coverage is 100% (empty schema is fully described). The description doesn't need to explain parameters, and it correctly avoids mentioning any. Baseline for 0 parameters is 4, as no parameter semantics are required.

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 clearly states the tool's purpose with specific verbs ('Get') and resources ('user subscription information'), listing the data returned (status, credit usage, plan details, renewal status). It distinguishes itself from sibling tools which focus on creating/managing content rather than retrieving subscription data. However, it doesn't explicitly differentiate from potential subscription-related siblings (none exist in the provided list).

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication needs), frequency of use, or relationships with other tools. Given that sibling tools are all about content creation/status checks, the implicit context is subscription queries, but no explicit usage rules are stated.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 8 tool updatesv1.0.0
    • Changedcreate_flowspeech2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedcreate_podcast2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedcreate_podcast_text_only2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedgenerate_podcast_audio2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedget_flowspeech_status2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedget_podcast_status2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedget_speakers2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedget_user_subscription2 fields changed
      • addedInput schema / $schema
        Added value: +"http://json-schema.org/draft-07/schema#"
      • addedInput schema / additionalProperties
        Added value: +false
  2. 8 tool updates
    • First observedcreate_flowspeech
    • First observedcreate_podcast
    • First observedcreate_podcast_text_only
    • First observedgenerate_podcast_audio
    • First observedget_flowspeech_status
    • First observedget_podcast_status
    • First observedget_speakers
    • First observedget_user_subscription
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.1/5.0

Scored across 8 tools

Disambiguation4/5

Most tools have distinct purposes, but there is some overlap between create_podcast and create_podcast_text_only + generate_podcast_audio, as they both handle podcast creation with different workflows. The descriptions clarify the differences, but an agent might initially be confused about which to use for text-only vs. full generation.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case, such as create_flowspeech, get_podcast_status, and get_speakers. This predictability makes it easy for agents to understand and navigate the tool set without confusion.

Tool Count5/5

With 8 tools, the server is well-scoped for its podcast and speech generation domain. The tools cover creation, status checking, resource management, and user information, providing a balanced set without being overwhelming or insufficient for the intended workflows.

Completeness4/5

The tool set offers strong coverage for podcast and FlowSpeech generation, including creation, status retrieval, and speaker management. However, there is a notable gap in editing capabilities, as noted that there is no separate tool to edit scripts after generation, which could limit agent flexibility in iterative workflows.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Appeared in Searches