TTS For Free

Publish a video to YouTube or X

publish_video

Post a finished video to one of the user's connected accounts. Only call after the user explicitly agreed to publish and confirmed the title (YouTube) or post text (X): this posts publicly on their behalf. YouTube: posted right away, free, needs title; set privacy (default public). X: posted now or at scheduled_at, needs text (max 280 characters, links count as 23); costs credits charged only when the post goes out - tell the user the cost from get_publishing_status first. video_url must be a TTSForFree link: final_video_url from get_localization_status, or public_url of a video uploaded with create_upload_url.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "video_url": "<video_url>"
    },
    "name": "publish_video"
  }
}

Input Schema

Name	Required	Description
`tags`	No	YouTube tags, comma separated.
`text`	No	X post text.
`title`	No	YouTube title (no < or >).
`privacy`	No	YouTube visibility. Default public.
`platform`	No	Use when the user has exactly one account on that platform.
`video_url`	Yes	TTSForFree video link (final_video_url or public_url).
`account_id`	No	account_id from get_publishing_status. Required when several accounts share a platform.
`description`	No	YouTube description.
`scheduled_at`	No	X only: ISO 8601 time with offset, e.g. 2026-11-20T09:00:00+07:00. Omit to post now. Ask the user for their time zone if unclear.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 13, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations only declare the generic non-read-only, non-idempotent profile; the description adds far more: content becomes public on the user's behalf, YouTube posts immediately and is free, X posts now or at scheduled_at, and credits are charged only at send time. It also pins the accepted source of video_url to two specific producing tools, which is real behavioral context an agent cannot get from 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?

Front-loaded with the consent gate before any mechanics, and every clause carries information (cost, timing, platform requirements, URL provenance). It is dense and single-paragraph, so it is slightly harder to scan than it could be, but there is no filler to cut.

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?

For a 9-parameter, no-output-schema publishing tool, the description covers consent, cost disclosure, per-platform required fields, scheduling semantics, and video_url provenance. Account selection is handled by the schema's own account_id/platform descriptions, so nothing critical is missing.

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 3, but the description goes well beyond it by imposing cross-field conditionals the schema cannot express: `title` is needed for YouTube, `text` for X (max 280, links count as 23), and `privacy` defaults to public. It also constrains `video_url` to outputs of get_localization_status or create_upload_url.

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 ("Post a finished video to one of the user's connected accounts") and then splits the behavior by platform (YouTube vs X) with each platform's required field. An agent can distinguish this from list_published_posts or cancel_scheduled_post without opening the 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?

Explicit gating: "Only call after the user explicitly agreed to publish and confirmed the title (YouTube) or post text (X)", plus a mandatory checkout step — "tell the user the cost from get_publishing_status first". This is when-to-use, prerequisite, and human-in-the-loop all in one, with no inference required.

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

All TTS For Free 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?