Skip to main content
Glama

audit_channel

Read-only

Give the signed-in user a full audit and overview of THEIR OWN YouTube channel in one answer: the overall state right now, what is working and why, which single thing is constraining the channel (whether people are not being SHOWN the videos or are being shown and not clicking), and what their audience wants. This is the broad front-door command, and it reads the channel as a whole. For a ranked list of which VIDEOS to fix first and in what order, call diagnose_channel instead. Call it when the user asks to audit, analyze, review, assess, evaluate, or check their channel; wants a channel overview, health check, summary, or the big picture; or asks broad questions like 'how is my channel doing', 'what is going on with my channel', 'analyze my channel', or 'give me my channel overview'. ALWAYS pass ask: 'broad' when they asked to audit/review/analyze the channel or how it is doing overall, 'specific' when they asked for the channel read but aimed it at ONE thing (an audit focused on their titles, a review that only cares about packaging). Pass refresh: true ONLY when they explicitly want the numbers re-pulled rather than the last saved read (they say it is out of date, or they just published and want it counted); it is slower and Klyf Pro only. This is a SNAPSHOT of right now: for anything about direction over time (is it growing or sliding, why growth stalled, is this month better than last) call check_growth instead, or first, since a snapshot cannot see a trend and will contradict it. Always about the user's own connected channel, never a competitor's. Needs no input: it reads their real connected YouTube channel directly. Never ask the creator anything first, not for context, not for a link, not for a title you could look up; call it immediately.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
askNoHow wide the user's question is. 'broad' when they asked for an audit, an overview, or how the channel is doing overall. 'specific' when they asked for the whole-channel read but pointed it at ONE thing, for example 'audit my channel, focus on my titles' or 'review my channel, is my packaging the problem'. Do NOT reach for 'specific' on a narrow question that belongs to another tool: what to fix first is diagnose_channel, why growth stalled is check_growth, and reaching new people is check_discoverability. A broad ask opens by describing what the channel is and who it serves; a specific one answers only what was asked. Default is broad.
refreshNoRecompute from YouTube instead of reading the last saved analysis. Klyf Pro only; takes noticeably longer

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds value by stating that refresh=true is slower, Klyf Pro only, and requires explicit user request, and that the tool reads a live snapshot of the user's channel. It does not cover error behavior or rate limits, but given the annotations, the added context is substantial.

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?

The description is front-loaded with the core purpose and then flows into usage and parameters. It is somewhat verbose, but every sentence contributes to routing or parameter clarification. The structure is logical and easy to parse.

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?

Given the tool's complexity (broad-channel audit), the presence of a detailed schema for parameters, and no output schema, the description is complete. It covers purpose, usage, alternatives, parameter guidance, and behavioral caveats (refresh slowness, Pro-only). It leaves no critical gaps for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents the two parameters. The description repeats the enum meanings and adds context for refresh ('slower', 'Klyf Pro only'), but does not add significant meaning beyond what is already in the schema descriptions.

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?

The description uses specific verbs (audit, overview, read as a whole) and explicitly distinguishes itself from siblings diagnose_channel and check_growth. An agent can understand exactly what this tool does and how it differs from the alternatives.

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

Usage Guidelines5/5

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

It provides explicit when-to-use criteria ('when the user asks to audit, analyze, review, assess, evaluate, or check their channel') and gives clear alternatives for overlapping needs (diagnose_channel for ranked list, check_growth for trends). It also includes example phrases, making the routing unambiguous.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources