yutu: a YouTube CLI, MCP server and agent built on the YouTube Data API

The problem yutu targets: YouTube's API is not the hard part, the credential dance is

The YouTube Data API v3 is a competent REST API. What slows people down is everything around it: creating a Google Cloud project, enabling the right APIs, building an OAuth consent screen, registering a Desktop app client, downloading client_secret.json, and then refreshing a token that expires every 3,599 seconds. yutu's README walks through exactly that sequence, which is a fair signal of who the tool is for. It is aimed at developers and operators who already know they want programmatic access to a channel and do not want to write the OAuth plumbing themselves. The stated scope is broad: uploading and optimizing videos, managing comments, playlists and channel branding. That breadth matters, because it means yutu is closer to a thin, opinionated client over the Data API than to a single-purpose uploader. The audience is correspondingly narrow: if you only ever upload one video a month through the web UI, nothing here applies to you.

One Go binary, three interfaces: CLI, MCP server and agent

The repository describes yutu as a CLI, an MCP server and an AI agent. The CLI is the substrate. The MCP server exposes the same operations over the Model Context Protocol so an agent host can call them as tools, and the README links to an asciinema recording of an MCP demo rather than describing the protocol surface in text. That is a deliberate emphasis: the project treats the CLI as the source of truth and the MCP layer as a transport. The agent path is the loosest of the three. Rather than shipping a fixed agent, the README hands you a prompt that points at internal/tools/skillgen/setup.md and tells an existing agent to follow it. The practical consequence is that the agent's behaviour depends on which model you point at that file, not on anything yutu pins down. The Go implementation is what ties all of this together: one binary, one credential store, one set of subcommands, and three ways to reach them.

Getting a token: yutu auth and the two JSON files it reads

Setup starts outside yutu. You create a GCP project, enable the YouTube Data API v3 (required) and optionally the YouTube Analytics and YouTube Reporting APIs, then create an OAuth client ID of type Desktop app and save the download as client_secret.json. The README shows the expected shape, an installed object with client_id, project_id, auth_uri, token_uri, auth_provider_x509_cert_url, client_secret and redirect_uris set to http://localhost. From there the command is yutu auth --credential client_secret.json. A browser opens, you grant access, and yutu writes youtube.token.json containing access_token, token_type, refresh_token, expiry and expires_in. Both files default to the current directory. The --credential/-c and --cacheToken/-t flags exist only on the auth subcommand, which is a real constraint: you cannot point a later subcommand at a differently named credential file with a flag. To change the path everywhere you set YUTU_CREDENTIAL and YUTU_CACHE_TOKEN, and the README notes these accept a path, a Base64 blob, or inline JSON. YUTU_ROOT controls the root directory for file resolution, and YUTU_LOG_LEVEL takes DEBUG, INFO, WARN or ERROR, defaulting to INFO.

Installation channels and what the Docker and npm paths imply

yutu is distributed several ways. There are prebuilt binaries on the releases page, an npm package published as @eat-pray-ai/yutu, a Homebrew formula, a WinGet package under the identifier eat-pray-ai.yutu, and a Docker image (the README's Docker section is truncated in the material available here, so the exact image tag cannot be confirmed). Two GitHub Actions are maintained separately: youtube-action for general use and youtube-uploader for video uploads. The breadth of packaging is a maintenance signal in both directions. It lowers the cost of trying yutu on macOS, Windows, Linux or inside a container. It also means the project maintains release plumbing across four package managers plus Docker, and the current release line is still on development tags. The three most recent releases listed are v0.10.11-dev1, v0.10.11-dev2 and v0.10.11-dev3, dated between late July and late August 2026. That is a pre-release cadence, not a stable one.

The constraint nobody escapes: Google's quota, consent screen and your own credentials

yutu does not remove any of Google's requirements. You still need a Google Cloud account. You still need to configure an OAuth consent screen and add yourself as a test user, which the README states plainly. You still operate under the YouTube Data API v3 quota, which the API enforces per project, not per tool, and a video upload consumes a large share of the default daily allowance. Because yutu authenticates as you against your own project, every write it performs is charged to your quota and attributed to your credentials. The failure mode is therefore mundane and predictable: a batch of uploads or comment operations exhausts the daily quota, and subsequent calls fail with quota errors rather than anything yutu-specific. The README does not document retry behaviour, backoff or quota accounting, so treat a mid-batch failure as something you must handle at the call site. A second limitation is environmental. yutu reads client_secret.json and youtube.token.json from the current directory by default, so a process started from the wrong working directory will not find them unless YUTU_ROOT or the environment variables are set. In a container or a scheduled job this is the most likely first failure.

Where yutu is the wrong tool, and what to use instead

If your requirement is a scheduled pipeline that runs whether or not a machine is up, yutu's local-credential model is the wrong fit. The project does ship GitHub Actions, and youtube-uploader is explicitly the upload-focused one, so a CI-based workflow is a supported path rather than a workaround. But that still leaves the credential problem: you must get client_secret.json and a valid token into the runner, and the README's environment variables accept Base64 or inline JSON specifically so this is possible, at the cost of storing a refresh token as a secret. For teams that would rather not own OAuth at all, the honest alternative is to work directly against the YouTube Data API v3 with a Google-maintained client library in your own language. The difference is not capability, since yutu is itself a client over that same API. The difference is control: your own client means you decide which scopes you request, how tokens are stored and rotated, and how quota errors are surfaced. You write more code and you get a smaller blast radius. Conversely, if you want an agent host such as Claude or another MCP-capable client to drive channel operations through tool calls, writing that MCP server yourself is a substantial amount of work that yutu already did.

Maintenance, licensing and what to check before you depend on it

yutu is Apache-2.0, which permits commercial and closed-source use and includes an explicit patent grant. That is permissive, but the licence does not cover the YouTube API terms of service, which govern your usage independently of yutu's licence. You are bound by Google's terms regardless of which client you call the API with, and yutu's Apache-2.0 grant gives you nothing on that front. On maintenance, the release history shows a steady stream of v0.10.11 development tags rather than a stable v1 line, and the repository is not archived. The upgrade cost is shaped by the credential contract: YUTU_CREDENTIAL, YUTU_CACHE_TOKEN, YUTU_ROOT and YUTU_LOG_LEVEL are the interface your deployment depends on, so pin a version and read the release notes before moving. Because the token file format is Google's, not yutu's, a yutu upgrade is unlikely to invalidate an existing token, but the default file paths and flag availability have already moved once (the -c and -t flags being auth-only is itself a narrowing). Anyone adopting yutu should decide early whether they are pinning the binary or tracking releases, because the pre-release tag cadence makes tracking the default branch a poor choice for anything unattended.

Editorial conclusion

Adopt yutu if you already have a Google Cloud project with the YouTube Data API v3 enabled and you want channel operations driven from a shell or from an MCP-capable agent. Do not adopt it if you need a hosted scheduler that keeps running when your laptop is closed, or if you want to avoid Google's OAuth consent screen entirely. Before committing, verify three things in your own project: that youtube.token.json is written where you expect, that YUTU_CREDENTIAL resolves correctly when the process runs outside the repository directory, and that your YouTube Data API v3 daily quota covers the number of write calls your workflow issues.

Official sources

1. eat-pray-ai/yutu on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases