YouTube Studio MCP

Overview Schema Source Related Servers Discussions Admin

Impressions & CTR (beta)

get_impressions

Read-onlyIdempotent

Retrieve thumbnail impressions and click-through rate by day, video, or total for a chosen period. Use it to track how often thumbnails appear in feeds and how often viewers click.

Instructions

Thumbnail impressions and impressions click-through rate (CTR) from the YouTube Reporting API, by day, by video, or in total. Requires enable_impressions_reports to have been run at least ~2 days earlier; only days YouTube has published are included.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_impressions"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	Maximum rows for group_by='video'.
`period`	No	Named date range, Studio-style. Rolling ranges end at the latest complete day of data (analytics lag ~2-3 days; dates are US Pacific). Ignored when start_date is set.	last_28_days
`end_date`	No	Custom range end, YYYY-MM-DD (inclusive). Defaults to the latest complete day.
`group_by`	No	Daily trend, per-video ranking, or one total for the period.	total
`start_date`	No	Custom range start, YYYY-MM-DD. Overrides `period`.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 11, 2026

TDQS

A3.8/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real value beyond that by disclosing the reporting-pipeline dependency and that only YouTube-published days are returned. It does not mention quota/rate-limit behavior or row caps, which matter for a reporting API tool.

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?

Two tight sentences with no filler; the resource is front-loaded and the operational caveat follows immediately. Every clause contributes information.

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?

With a full output schema, rich annotations and complete parameter documentation, the description covers the two non-obvious facts an agent needs: the setup prerequisite and the data lag/published-days limitation. Rate limits and result-size behavior are the remaining gap.

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 period, group_by, limit and date ranges are already fully documented in the schema. The description's 'by day, by video, or in total' merely restates the group_by enum without adding format or interaction detail, so the baseline 3 applies.

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?

Names a specific resource (thumbnail impressions and impressions CTR from the YouTube Reporting API) and the supported granularities (by day, by video, or in total). It clearly signals this is impressions/CTR data rather than general analytics, but does not explicitly differentiate itself from siblings like get_metrics_over_time or get_performance_summary.

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?

Gives a concrete prerequisite: enable_impressions_reports must have been run at least ~2 days earlier, which tells the agent when this tool will return useful data. It stops short of naming when to prefer an alternative tool for the same metric family.

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