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

> yutu wraps the YouTube Data API v3 in a Go CLI that also speaks MCP and ships an AI agent. It is aimed at people who already have a Google Cloud project and want their YouTube workflow driven from a terminal or an assistant.

**eat-pray-ai/yutu** — The AI-powered toolkit that grows your YouTube channel on autopilot.

- Repository: https://github.com/eat-pray-ai/yutu
- Website: https://yutu.ifor.dev
- Stars: 694 · Forks: 83
- Language: Go
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/eat-pray-ai-yutu

## The gap yutu fills between the YouTube Studio UI and scripted uploads

Most YouTube automation starts with a Python script that copies the quickstart sample from Google's API docs. It works until you need comments, playlists, thumbnails and channel branding in the same run, at which point you are maintaining several half-finished scripts. yutu's answer is to package the whole surface as one command tree. The README describes it as a CLI, MCP server and AI agent for YouTube that covers uploading and optimizing videos plus comments, playlists and channel branding.

The audience is narrow and specific. You need a Google Cloud Platform account, you need to enable the YouTube Data API v3 (the Analytics and Reporting APIs are marked optional), and you need to create OAuth credentials of the Desktop app type. That is a real setup cost. In exchange, the tool never holds your credentials on someone else's server: the OAuth client secret and the cached token live in files you control. If you have ever wanted to move a channel's operations into a shell script or a CI job, this is the shape of tool you were looking for.

## How the CLI, MCP server and agent share one command tree

The dependency list in go.mod explains the architecture better than the README does. The project depends on spf13/cobra and spf13/pflag, so the CLI is a standard Cobra command tree. It also depends on github.com/eat-pray-ai/cobra-mcp and github.com/modelcontextprotocol/go-sdk, which is the mechanism that turns that same command tree into an MCP server for assistants such as Claude. The agent side pulls in google.golang.org/adk/v2 and google.golang.org/genai, and golang.org/x/oauth2 plus google.golang.org/api handle authentication and the YouTube calls themselves.

That layout has a practical consequence. There is one definition of each operation, and the CLI and the MCP tools are two front ends onto it. A command you can run in a terminal is also a tool an MCP client can call, which is why the README can advertise a single toolkit rather than two products. The Dockerfile reinforces the design: the final image is built FROM scratch, exposes port 8216/tcp, and copies only the CA certificates and the binary, with ENTRYPOINT ["/yutu"]. A scratch image means no shell inside the container, so anything you want to do has to be expressible as a yutu subcommand or as an argument passed to the entrypoint.

## Installing yutu and running the first authenticated command

The README points at the releases page for a direct download and lists package-manager routes. The npm package is published as @eat-pray-ai/yutu, so a global install is one command.

```bash
npm i -g @eat-pray-ai/yutu
```

Homebrew and WinGet are also referenced through their badges (the formula is yutu, the WinGet package is eat-pray-ai.yutu). If you prefer containers, the Dockerfile builds a scratch image that exposes port 8216.

Before any command can talk to YouTube you must create a GCP project, enable the YouTube Data API v3, and download a Desktop app OAuth client saved as client_secret.json. The README gives the expected file shape, including the installed block with client_id, project_id, client_secret and a redirect_uris entry of http://localhost. With that file in the current directory, authentication is:

```bash
yutu auth --credential client_secret.json
```

A browser window opens for the consent flow, and the resulting token is written to youtube.token.json. Every later subcommand reads client_secret.json and youtube.token.json from the working directory by default. The flags --credential/-c and --cacheToken/-t exist only on the auth subcommand; to change the paths for everything else you set environment variables instead. YUTU_CREDENTIAL and YUTU_CACHE_TOKEN accept a path, Base64 or raw JSON, YUTU_ROOT sets the file-resolution root, and YUTU_LOG_LEVEL takes DEBUG, INFO, WARN or ERROR with INFO as the default. The README also offers a single prompt to hand to an AI agent that points at the setup document in the repository, which is the fastest path if you would rather not follow the GCP console steps by hand.

## Where yutu gets in your way

The prerequisites are the limitation. You cannot use yutu without your own Google Cloud project and OAuth client, and the README's consent-screen instructions have you add yourself as a test user. That is fine for a single operator, and it is the reason the tool is safe to run locally, but it also means there is no shared team credential model described anywhere in the README. Everyone who runs it needs their own client secret and token, or needs to be handed yours.

The second constraint is release cadence. The most recent releases listed are v0.10.11-dev1, v0.10.11-dev2 and v0.10.11-dev3, dated 2026-07-26, 2026-08-01 and 2026-08-20. These are development tags, not a stable v0.10.11. If your pipeline pins versions, you are pinning a dev build. The last push to the repository was on 2026-09-07.

Finally, the scratch Docker image removes the fallback you would normally reach for. There is no shell in the container, so debugging a failed call means reading logs at the level you configured through YUTU_LOG_LEVEL rather than poking around inside the image. The README does not document a rollback procedure for token or credential changes, so treat the token file as something you back up before experimenting.

## yutu against the Google API client libraries it is built on

The obvious alternative is not another YouTube tool but the official google.golang.org/api client, or the Python and JavaScript equivalents, used directly. yutu is built on exactly that library, so the comparison is about what the extra layer buys and costs.

Writing against the raw client gives you full control over request construction, batching and error handling, and it will never lag behind a new API field. It also means you write the command parsing, the credential loading, the token caching and the output formatting yourself, and you redo that work for every language you support. yutu trades that control for a fixed command vocabulary and a consistent output layer (the go-pretty dependency in go.mod suggests tabular terminal output). The MCP server is the part you cannot easily reproduce on your own: exposing the same operations to an assistant requires implementing the protocol and describing each tool's schema, which is what the cobra-mcp and modelcontextprotocol/go-sdk dependencies do here. If you only ever need to upload a file from a script, the raw client is less machinery. If you want the same operations available to a person in a terminal and to an agent over MCP, the shared command tree is the reason to pick yutu.

## Licence, upgrades and what maintenance actually looks like

yutu is Apache-2.0, and the Dockerfile carries the SPDX identifier Apache-2.0 alongside a copyright line naming eat-pray-ai and OpenWaygate. Apache-2.0 includes an explicit patent grant and requires you to preserve notices and state significant changes when you redistribute. For internal use of the binary, that mostly means keeping the LICENSE file with any copy you ship. This is a description of the licence text, not legal advice; if you are redistributing yutu inside a product, read the licence yourself.

Upgrade cost is low if you install through a package manager, because npm, Homebrew and WinGet each track their own version of the tool. It is higher if you build the Docker image, since the Dockerfile expects prebuilt binaries in dist/ named through the arm64_binary and amd64_binary build arguments, which means you are responsible for producing the release artifacts before the image build. The repository also carries Bazel files (MODULE.bazel, BUILD.bazel, .bazelrc, .bazelversion) alongside go.mod, so there are two build systems to keep working if you build from source. Check which one the release workflow uses before you script a build.

## Conclusion

Adopt yutu if you already run a Google Cloud project, are comfortable with OAuth desktop credentials, and want YouTube operations exposed as CLI commands or MCP tools rather than a web dashboard. Skip it if you want a hosted service that holds your credentials, or if you need a stable release rather than the v0.10.11-dev line the repository currently publishes. Before committing, verify two things yourself: that your OAuth consent screen is configured with yourself as a test user, and that the API surface you need (uploads, playlists, comments, analytics) is enabled for your project.

## FAQ

### What is yutu?

yutu is a CLI, MCP server and AI agent for YouTube, written in Go and licensed Apache-2.0. According to the README it automates uploading and optimizing videos as well as managing comments, playlists and channel branding.

### How do I install yutu?

The README lists a direct download from the releases page plus package-manager routes, including a global npm install of @eat-pray-ai/yutu, a Homebrew formula named yutu, a WinGet package named eat-pray-ai.yutu and a Docker image. It also provides a prompt that points an AI agent at the setup document in the repository.

### What do I need before running yutu for the first time?

A Google Cloud Platform account with the YouTube Data API v3 enabled, and an OAuth client of the Desktop app type downloaded as client_secret.json. The YouTube Analytics and Reporting APIs are listed as optional. Authentication then runs through yutu auth, which saves a token to youtube.token.json.

### Where does yutu keep my credentials?

By default it reads client_secret.json and youtube.token.json from the current directory. YUTU_CREDENTIAL and YUTU_CACHE_TOKEN can each be set to a path, Base64 or raw JSON to change that, and YUTU_ROOT sets the root directory used for file resolution.

### Is yutu stable enough to pin in a pipeline?

The most recent releases listed are v0.10.11-dev1, v0.10.11-dev2 and v0.10.11-dev3, so the current line is a development tag rather than a stable v0.10.11. The repository's last push was on 2026-09-07.

## Sources

- [eat-pray-ai/yutu on GitHub](https://github.com/eat-pray-ai/yutu)
- [License: Apache-2.0](https://github.com/eat-pray-ai/yutu/blob/main/LICENSE)
- [Project website](https://yutu.ifor.dev)
- [README](https://github.com/eat-pray-ai/yutu/blob/main/README.md)
- [Releases](https://github.com/eat-pray-ai/yutu/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/eat-pray-ai-yutu