youtube-kit

Overview Schema Source Related Servers Discussions Admin

Upload Video

upload_video

Upload a local video file to YouTube with resumable transfer and progress reporting, then set title, privacy, tags, category, and optional scheduling.

Instructions

Upload a video file from disk (resumable, reports progress).

Category and languages left out are copied from your most recent public upload (among your last 150), so the video matches the rest of your channel; with none, the category is 22 (People & Blogs). YouTube keeps processing the video after this returns, and its duration and statistics appear only once that ends. Checking whether processing has finished tells you when, or why it failed.

Quota: 1607 units.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`file`	Yes	Path to the local video file.
`tags`	No	Keyword tags. YouTube may store them in a different order.
`title`	Yes	Video title.
`privacy`	No	Privacy status. Must be private when publish_at is set.	private
`language`	No	Language of the title and description, e.g. en-US.
`ai_content`	No	Whether AI made realistic content: a real person saying or doing something they didn't, altered footage of a real event or place, a realistic scene that didn't happen, or music that's the video's focus. Not for scripts, captions, or obviously unreal content.
`my_channel`	No	Which of your logged-in channels to work on: UC… ID, @handle or exact title. Omit for the default channel.
`publish_at`	No	Schedule publication at this date or datetime; YouTube makes the video public then.
`category_id`	No	Category ID (see the video categories listing).
`description`	No	Video description.
`made_for_kids`	No	Whether the video is made for kids (COPPA).
`audio_language`	No	Language spoken in the video, e.g. en-US.
`paid_promotion`	No	Whether the video includes paid promotion: a sponsorship, product placement, or endorsement.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes
`url`	Yes
`tags`	No	In the order YouTube stores them, which may differ from yours.
`stats`	No
`title`	No
`privacy`	No
`duration`	No
`language`	No	Language of the title and description, e.g. en-US.
`ai_content`	No	Declared to contain realistic AI-made content, as set by this upload or update. YouTube doesn't report it when reading a video.
`channel_id`	No
`publish_at`	No
`studio_url`	No	Edit page in YouTube Studio; only for videos on channels you're logged in to.
`category_id`	No
`description`	No
`published_at`	No
`channel_title`	No
`upload_status`	No	uploaded, processed, failed, rejected, or deleted.
`audio_language`	No	Language spoken in the video, e.g. en-US.
`paid_promotion`	No	Declared to include paid promotion.
`duration_seconds`	No
`rejection_reason`	No	Why YouTube rejected the video, e.g. copyright, duplicate, length, termsOfService. YouTube reports no reason for a video kept private because its API project isn't verified.
`upload_failure_reason`	No	Why a failed upload failed, e.g. codec, conversion, emptyFile, invalidFile, tooSmall.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 18, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Goes well beyond the annotations (readOnly=false, openWorld=true, idempotent=false, destructive=false) by disclosing default inheritance from the last 150 uploads, the category 22 fallback, resumability, quota cost (1607 units), and the critical async fact that YouTube keeps processing after return so duration/statistics are not immediately available. This is exactly the behavioral surface an agent needs.

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-loads the purpose, then layers defaults, async behavior, and quota. Dense and slightly clause-heavy, but each sentence (defaults, processing lag, quota) contributes operational detail, and nothing is redundant.

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 13-parameter write tool with an output schema, the description covers the non-obvious gaps: default-inheritance behavior, post-return processing, and quota cost. Return values are delegated to the output schema, which is appropriate.

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?

Schema description coverage is 100%, so the baseline is 3, but the description adds meaning the schema lacks: category and language default values are inherited from prior uploads rather than defaulting to null as the schema shows. That is genuine added value for two of the thirteen parameters.

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 ('Upload a video file from disk') and immediately frames scope with resumable/progress. An agent can trivially distinguish this from update_video or delete_video without opening a schema.

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

Usage Guidelines3/5

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

Usage is implied by the verb and the file/title requirement, but there is no explicit when-to-use or when-not-to-use guidance and no named alternative (e.g., update_video for modifying an existing upload). The pointer to processing-status checking is helpful context but not a tool-selection rule.

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