Skip to main content
Glama

publish_to_youtube

Publish an existing video from a transcribe or summarize job to YouTube. Creates a paid publish job (flat $1.75 price) and stores the OAuth token. Captions are auto-generated from the session transcript if available. Workflow: create_job → pay → trigger_youtube_publish → poll get_youtube_publish_status. Requires a YouTube OAuth2 access token obtained independently via Google OAuth (scope: youtube.upload).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYesYouTube video title (max 100 characters)
visibilityYesYouTube video visibility: "private" (default), "unlisted", or "public"private
descriptionNoYouTube video description (max 5000 characters)
access_tokenYesYouTube OAuth2 access token — the caller is responsible for obtaining this via Google OAuth
refresh_tokenNoYouTube OAuth2 refresh token — if provided, the Workflow will refresh the access token automatically before uploading
session_tokenYesSession token from create_session, create_transcript, or create_summary
source_job_idYesJob ID of an existing transcribe or summarize job in this session whose video to publish. The Workflow will auto-generate captions if no transcript is found.

TDQS

A4.2/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden. It discloses the $1.75 price, OAuth token storage, auto-generated captions, and the required OAuth scope, which are meaningful side effects and conditions. It does not cover failure modes or token expiry behavior, but the disclosed details go beyond a generic 'publish' statement.

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 sentences deliver purpose, side effects, caption behavior, workflow, and OAuth requirements without redundancy. Information is front-loaded and every sentence contributes.

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?

The description explains the overall process and points to get_youtube_publish_status for polling, covering the main constraints (existing job, OAuth token, cost). It does not describe the API response shape or failure handling, but given the workflow is explicit, the tool is sufficiently contextual for an agent.

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 already provides descriptions for all 7 parameters (100% coverage). The description adds workflow context and reiterates that captions are auto-generated, but does not add new parameter-specific semantics beyond what the schema already states. Thus, a baseline score of 3 is appropriate.

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 opens with a specific action—publishing an existing video from a transcribe or summarize job to YouTube—and clarifies it creates a paid publish job rather than directly uploading. It references the broader workflow, distinguishing itself from trigger_youtube_publish while naming it in the sequence.

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?

It states the prerequisite of an existing transcribe/summarize job and an independently obtained YouTube OAuth token, and lays out the full workflow (create_job → pay → trigger_youtube_publish → poll). It does not explicitly say when not to use this tool or directly compare with alternatives, leaving some room for confusion with the sibling trigger_youtube_publish.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation4/5

Most tools target distinct tasks (transcribe vs. summarize vs. find_clips, extract_clip vs. extract_vertical_clip, create vs. trigger YouTube). Some overlap exists because summarize and find_clips both produce transcripts, and publish_to_youtube and trigger_youtube_publish are sequential steps that could be confused, but descriptions clarify the boundaries well.

Naming Consistency4/5

The majority follow a verb_noun pattern (complete_upload, extract_clip, find_clips, get_job_status), with a few deviations like the bare verbs 'summarize' and 'transcribe', and 'publish_to_youtube' using a preposition. The pattern is still predictable and readable overall.

Tool Count5/5

11 tools is a well-scoped number for a video/audio processing service covering transcription, summarization, clip extraction, YouTube publishing, and payment testing. Each tool has a clear place, and the count is within the ideal range.

Completeness5/5

The tool surface covers the full lifecycle: job creation (transcribe/summarize/find_clips), payment (mpp_smoke_test, payment challenge flows), upload (complete_upload), status polling (get_job_status), clip extraction (two variants), and YouTube publishing (create/publish/status). No critical gaps are apparent for the stated domain.

Resources