Skip to main content
Glama

Connect a YouTube channel

connect_channel

Open Google sign-in to connect or reconnect a YouTube channel, returning the sign-in link and waiting for the user to pick an account and channel.

Instructions

Start Google sign-in to connect (or reconnect) a YouTube channel. Opens the browser on this computer and returns the sign-in link; the user picks the Google account and channel (brand accounts work). Waits up to wait_seconds for them to finish.

Input Schema

NameRequiredDescriptionDefault
open_browserNo
wait_secondsNoHow long to wait for the sign-in to finish before returning.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.1

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the annotations' mutation and open-world signals, the description discloses the local browser side effect, return of a sign-in link, required user interaction, support for brand accounts, and bounded waiting behavior. These details substantially clarify what invoking the tool will do and what the user must do next.

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 compact sentences front-load the purpose and then cover the interaction and timing behavior. Every phrase adds useful operational information without repetition or unnecessary background.

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 definition supplies enough information for an agent to initiate the connection flow correctly, including the browser, link, user choices, and wait limit. With no output schema, it could be more complete by describing what is returned on success versus timeout and how to proceed if the user does not finish signing in.

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?

The description explains the waiting behavior associated with wait_seconds and describes the default browser-opening flow relevant to open_browser, whose schema entry lacks a description. It does not explicitly explain that open_browser=false provides a link-only flow or clarify the practical effect of wait_seconds=0.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening sentence clearly identifies the action and resource: starting Google sign-in to connect or reconnect a YouTube channel. The account and channel selection details make its role easy to understand, although it does not explicitly contrast itself with siblings such as auth_status, set_default_channel, or disconnect_channel.

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 establishes that the tool is for both initial connection and reconnection, and that the user must participate by choosing a Google account and channel. It does not explain when reconnection is necessary or direct the agent to auth_status for checking an existing connection, but the intended usage context is clear.

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