This server provides agent-friendly tools for managing YouTube Shorts via the YouTube Data API, with dry-run safety, OAuth readiness checks, privacy audits, and structured output.
Get agent manifest (youtube_agent_manifest): Retrieve install, runtime, and safety guidance for specific agent clients (Codex, Claude, Cursor, etc.) in JSON or Markdown.
Check connection status (youtube_connection_status): Check dry-run mode, OAuth readiness, and live upload readiness without exposing sensitive token values.
Run privacy audit (youtube_privacy_audit): Review OAuth scopes, synthetic media flags, and local safety boundaries for live uploads.
Generate OAuth authorization URL (youtube_oauth_authorize_url): Generate a Google OAuth PKCE authorization URL and securely persist the PKCE verifier locally without returning it to the agent.
Upload a YouTube Short (youtube_upload_short): Upload a vertical video as a YouTube Short with title, caption, tags, privacy status (public/unlisted/private), and a contains_synthetic_media flag. Dry-run is default; live uploads require YOUTUBE_DRY_RUN=false.
List recent videos (youtube_list_recent_videos): List recent videos from the configured channel (up to 50 results) for post-upload verification.
Allows agents to upload YouTube Shorts videos via the YouTube Data API, with dry-run safety, OAuth readiness, and structured output for metadata and upload jobs.
Provides tools for uploading, validating, and managing YouTube Shorts videos, including synthetic media support and privacy audits.
Explicitly avoids automating YouTube Studio UI, focusing on API-based uploads.
ā If this agent-first tool helps your workflow, please star the repo. Stars make this tooling easier for other builders to discover and help Delx keep shipping open infrastructure. š§± Part of the Delx agent stack — 15 open-source MCP servers across body, reach and coordination.
Agent-first YouTube Shorts uploader for the YouTube Data API. It is designed for Codex, Claude, Cursor, Hermes, OpenClaw and any MCP client that needs a predictable upload workflow with dry-run safety, OAuth readiness checks and structured output.
Use it when an agent needs to prepare, validate or upload Shorts through the official API without touching YouTube Studio UI.
youtube_agent_manifest for install/runtime guidance
youtube_connection_status before upload attempts
youtube_privacy_audit for local token and media boundaries
youtube_oauth_authorize_url with local PKCE session storage
youtube_upload_short with containsSyntheticMedia support
youtube_list_recent_videos for lightweight post-upload checks
Related MCP server: framefetch
npm install -g youtube-shorts-agentOr run directly:
npm exec --yes --package=youtube-shorts-agent -- youtube-shorts-agent doctoryoutube-shorts-agent manifest --client codex
youtube-shorts-agent doctor
youtube-shorts-agent privacy-audit
youtube-shorts-agent auth-url --redirect-uri http://localhost:8787/callback
youtube-shorts-agent upload-short --video ./short.mp4 --title "Launch title" --caption-file copy.txt
youtube-shorts-agent list-recent --max-results 10Dry-run is enabled by default. Set YOUTUBE_DRY_RUN=false only when doctor reports a complete OAuth setup and you intend to call the live API.
This is the full first-run path. Every step here is dry-run safe ā no credentials are required and nothing is sent to YouTube. The output below is captured verbatim from a real run.
1. Check readiness. With no OAuth configured, doctor confirms you are in dry-run mode:
youtube-shorts-agent doctor{
"ok": true,
"dry_run": true,
"configured": {
"client_credentials": "missing",
"access_token": "missing",
"refresh_token": "missing"
},
"missing_count": 3,
"ready_for_live_upload": false,
"next_steps": [
"Current mode is dry-run. Validate metadata and agent flow before live uploads."
]
}2. Prepare a Short and its caption.
printf 'Launching the agent-first Shorts uploader.\n#shorts #ai #agents' > copy.txt
# short.mp4 is your vertical 9:16 clip3. Run the upload in dry-run. No network call is made; the tool returns the exact job and result it would publish, so an agent can validate metadata before going live:
youtube-shorts-agent upload-short \
--video ./short.mp4 \
--title "Agent-first Shorts upload" \
--caption-file copy.txt \
--tags ai,agents \
--duration 24{
"ok": true,
"dry_run": true,
"job": {
"id": "youtube_1780082215631",
"platform": "youtube",
"status": "queued",
"createdAt": "2026-05-29T19:16:55.631Z",
"caption": "Launching the agent-first Shorts uploader.\n#shorts #ai #agents",
"targetUrl": "",
"mediaPaths": ["./short.mp4"],
"metadata": {
"title": "Agent-first Shorts upload",
"youtube_title": "Agent-first Shorts upload",
"youtube_tags": ["ai", "agents"],
"youtube_contains_synthetic_media": true,
"video_duration_sec": 24,
"video_aspect_ratio": "9:16"
}
},
"result": {
"provider": "youtube_official",
"platformPostId": "dryrun_1780082215631",
"releaseUrl": "https://www.youtube.com",
"raw": { "dryRun": true, "jobId": "youtube_1780082215631" }
}
}platformPostId is prefixed with dryrun_ and releaseUrl is the YouTube root ā both signal that nothing was uploaded. The id, createdAt and dryrun_* values vary per run.
4. Confirm the channel listing path (returns an empty list in dry-run):
youtube-shorts-agent list-recent --max-results 5{ "items": [] }Going live. Configure OAuth (youtube-shorts-agent auth-url --redirect-uri http://localhost:8787/callback, then exchange the callback code for tokens), set YOUTUBE_CLIENT_ID / YOUTUBE_CLIENT_SECRET / YOUTUBE_ACCESS_TOKEN / YOUTUBE_REFRESH_TOKEN in .env, re-run doctor until ready_for_live_upload is true, then set YOUTUBE_DRY_RUN=false and re-run the same upload-short command.
youtube-shorts-mcpDefault is stdio. Optional Streamable HTTP ā no session id, JSON responses, loopback only:
npx -y -p youtube-shorts-agent youtube-shorts-mcp --http
# GET http://127.0.0.1:3032/health
# POST http://127.0.0.1:3032/mcp (sessionless)Env: YOUTUBE_MCP_HOST, YOUTUBE_MCP_PORT, YOUTUBE_MCP_TRANSPORT=http.
Hermes-style config:
mcp_servers:
youtube_shorts:
command: npx
args: ["-y", "youtube-shorts-agent"]
sampling:
enabled: falseRecommended first calls:
youtube_connection_status
youtube_privacy_audit
youtube_upload_short
Tool | Purpose |
| Install/runtime guidance for Codex, Claude, Cursor, Hermes and OpenClaw |
| OAuth and dry-run readiness without token values |
| Upload scope, synthetic media and local file boundaries |
| PKCE authorization URL with local session storage |
| Dry-run or live Shorts upload |
| Lightweight channel verification |
Use youtube-shorts-agent. First call youtube_connection_status and youtube_privacy_audit.
If uploading AI-generated media, keep containsSyntheticMedia=true. Never print token values.Copy .env.example to .env. Keep .env and .agent-data/ out of Git.
The upload tool sets containsSyntheticMedia=true by default for AI-generated or AI-edited videos. Override only when that is not true for the asset.
OAuth tokens are never returned by CLI or MCP tools.
PKCE verifier is stored locally in .agent-data/.
Live upload requires YOUTUBE_DRY_RUN=false.
The package uses the official YouTube Data API and does not automate Studio UI.
npm install
npm test
npm run checkšØ support@delx.ai ā general questions, integration help, partnerships
š Bug reports / feature requests ā GitHub Issues
š¦ Updates ā @delx369 on X
š Site ā wellness.delx.ai
Machine-readable install, client, runtime and safety guidance for agents.
| Name | Required | Description | Default |
|---|---|---|---|
| client | No | generic | |
| response_format | No | json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the tool provides 'install, client, runtime and safety guidance', which gives some behavioral context beyond annotations but does not detail return behavior or side effects. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it lacks a clear structure and does not front-load the most critical information about what the tool does. It could be more informative without increasing length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (2 optional params, no output schema, presence of annotations), the description is incomplete. It does not explain what the manifest contains, what the tool returns, or how the output should be used. This leaves ambiguity for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for its two parameters ('client' and 'response_format'). The description does not mention or explain these parameters, leaving the agent to infer their meaning from names alone. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Machine-readable install, client, runtime and safety guidance for agents' is somewhat vague and does not use a strong action verb. It conveys the tool provides configuration guidance but lacks specificity about its exact function, such as retrieving a manifest document. It partially distinguishes from sibling tools which perform actions like listing videos or uploading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when or why to use this tool versus alternatives like youtube_connection_status or youtube_privacy_audit. It does not mention any prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check dry-run mode, OAuth readiness and live upload readiness without exposing tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent. The description adds value by specifying the exact readiness aspects checked (dry-run, OAuth, live upload) and explicitly states tokens are not exposed, providing useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the tool's purpose and key safety detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one optional parameter, no output schema, clear annotations), the description provides all necessary context: what is checked, that tokens are not exposed, and the read-only nature is reinforced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention the 'response_format' parameter or its enum values. Since the parameter is simple, the oversight is minor but still fails to add meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks dry-run mode, OAuth readiness, and live upload readiness, which is a specific verb and resource. It distinguishes from siblings like youtube_oauth_authorize_url and youtube_upload_short by focusing on status checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing readiness status, but lacks explicit guidance on when to use vs alternatives or exclusions. It does not mention when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent videos from the configured YouTube channel.
| Name | Required | Description | Default |
|---|---|---|---|
| max_results | No | ||
| response_format | No | json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, etc. The description adds only that it accesses a configured channel, which is basic context. Lacks details on rate limits or result ordering.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise with no unnecessary words, but could benefit from a slightly more structured breakdown.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a tool without output schema; it does not explain what 'recent' means, how results are ordered, or pagination behavior, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions), and the tool description does not mention or explain any parameters (max_results, response_format), leaving the agent without guidance beyond the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'list' and resource 'recent videos from the configured YouTube channel', distinguishing it from siblings like youtube_upload_short or privacy_audit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the simple purpose, but no explicit guidance on when to use vs. other tools (e.g., for searching) or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a Google OAuth authorization URL and persist the PKCE verifier locally without returning it to the agent.
| Name | Required | Description | Default |
|---|---|---|---|
| state | No | ||
| scopes | No | ||
| redirect_uri | Yes | ||
| response_format | No | json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the PKCE verifier is persisted locally and not returned, which is a significant behavioral trait not covered by annotations. However, it does not mention that a user interaction is required to complete OAuth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded with the main action, but at the cost of omitting parameter details and usage context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of OAuth and no output schema, the description fails to explain what the agent should do with the returned URL, nor does it mention security considerations or integration with sibling tools like youtube_connection_status.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to any of the 4 parameters (state, scopes, redirect_uri, response_format). The agent lacks context for required and optional fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Google OAuth authorization URL and persists the PKCE verifier locally, distinguishing it from sibling tools that handle other YouTube operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives or prerequisites. The description does not mention that this should be called before other YouTube tools or explain the OAuth flow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return OAuth scope, synthetic media and live-upload safety boundaries.
| Name | Required | Description | Default |
|---|---|---|---|
| response_format | No | json |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds value by specifying the exact data returned (OAuth scope, safety boundaries), which is beyond the generic read-only indication. It does not contradict annotations, and the added context helps the agent understand the output nature, though it could mention any special requirements like authentication status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core function without any unnecessary words. It is appropriately concise for a simple tool, though the brevity sacrifices detail on parameters and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one optional parameter, no output schema), the description adequately lists the three return components. However, it does not describe the structure or format of the response, leaving some ambiguity about what exactly is returned under each category. A more complete description would include example values or a note about the response format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'response_format' has enum values (json, markdown) and a default of 'json', but the description does not mention this parameter or explain its effect. With 0% schema description coverage, the description fails to compensate by clarifying how the parameter controls output format, which is essential for agent decision-making.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return' and the resource 'privacy audit info', listing three specific components (OAuth scope, synthetic media, live-upload safety boundaries). It distinguishes this tool from siblings like youtube_upload_short or youtube_list_recent_videos by focusing on privacy audit rather than operations. However, the description could be more explicit about what each component entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like youtube_oauth_authorize_url or youtube_connection_status. It does not specify prerequisites, use cases, or situations where this tool is preferred, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload one vertical video as a YouTube Short. Dry-run is enabled by default; live mode requires YOUTUBE_DRY_RUN=false.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| title | Yes | ||
| caption | No | ||
| video_path | Yes | ||
| privacy_status | No | public | |
| response_format | No | json | |
| contains_synthetic_media | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the dry-run behavior beyond what annotations provide (which only indicate mutability). Annotations show readOnlyHint=false and destructiveHint=false, consistent with upload. The vertical video constraint is noted, but missing details like auth requirements or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and contains no filler. Every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters including required fields and enums, and no output schema, the description is too minimal. It does not explain how to specify the video path, title requirements, or effects of optional parameters like privacy_status. The agent lacks sufficient guidance for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description offers no explanation for any of the 7 parameters (e.g., video_path, title, tags, privacy_status). The description only covers the tool's primary purpose but leaves parameter meaning entirely to the schema with no additional guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool uploads one vertical video as a YouTube Short. This verb-resource combination is distinct from sibling tools like youtube_list_recent_videos or youtube_oauth_authorize_url.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions dry-run default and live mode requirement, providing some context but no explicit when-not-to-use or comparison to alternatives. Siblings are different enough to not require detailed exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.6youtube_agent_manifestyoutube_connection_statusyoutube_list_recent_videosyoutube_oauth_authorize_urlyoutube_privacy_audityoutube_upload_shortEach tool serves a clear, distinct purpose: manifest info, connection status, listing videos, OAuth URL generation, privacy audit, and upload. No functional overlap.
All tools follow the consistent pattern 'youtube_verb_noun', making it easy to predict tool behavior from names alone.
With 6 tools covering auth, status, listing, upload, and audit, the count is well-scoped for a YouTube Shorts agent without unnecessary bloat.
Core workflows (upload, list, OAuth, status check) are covered. Minor gaps like deletion or metadata editing are acceptable for a focused shorts agent.
Transcode and host video from one prompt; get a playable link back. Agent-native, over MCP.
MCP server for QPost ā lets AI agents publish video and image posts to YouTube, TikTok, Instagram.
Turn long videos into short, captioned viral clips from your AI assistant. 28 tools, OAuth.
Clip videos into captioned shorts, add captions, and schedule posts from AI agents.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/davidmosiah/youtube-shorts-agent'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
