NotebookLM MCP Server

studio_create

Create any NotebookLM studio artifact, including audio, video, infographics, slides, reports, flashcards, quizzes, data tables, and mind maps, from notebook sources.

Instructions

Create any NotebookLM studio artifact. Unified creation tool.

Supports: audio, video, infographic, slide_deck, report, flashcards, quiz, data_table, mind_map

Args: notebook_id: Notebook UUID artifact_type: Type of artifact to create: - audio: Audio Overview (podcast) - video: Video Overview - infographic: Visual infographic - slide_deck: Presentation slides (PDF) - report: Text report (Briefing Doc, Study Guide, etc.) - flashcards: Study flashcards - quiz: Multiple choice quiz - data_table: Structured data table - mind_map: Visual mind map source_ids: Source IDs to use (default: all sources) confirm: Must be True after user approval

Type-specific options:
- audio: audio_format (deep_dive|brief|critique|debate), audio_length (short|default|long)
- video: video_format (explainer|brief|cinematic), visual_style (auto_select|custom|classic|whiteboard|kawaii|anime|watercolor|retro_print|heritage|paper_craft), video_style_prompt
- infographic: orientation (landscape|portrait|square), detail_level (concise|standard|detailed), infographic_style (auto_select|sketch_note|professional|bento_grid|editorial|instructional|bricks|clay|anime|kawaii|scientific)
- slide_deck: slide_format (detailed_deck|presenter_slides), slide_length (short|default), orientation (landscape|portrait)
- report: report_format (Briefing Doc|Study Guide|Blog Post|Create Your Own), custom_prompt
- flashcards: difficulty (easy|medium|hard)
- quiz: question_count (int), difficulty (easy|medium|hard)
- data_table: description (required)
- mind_map: title

Common options:
- language: BCP-47 code (en, es, fr, de, ja, vi) OR friendly name (English, Vietnamese, French...). Defaults to NOTEBOOKLM_HL env var or 'en'. NOTE: "Vietnamese" is auto-mapped to "vi".
- focus_prompt: Optional focus text

Slide deck orientation note:
- NotebookLM has no native 9:16 field for slide_deck. Passing
  orientation="portrait" auto-prepends an English directive
  ("Create a slide deck for TikTok (Vertical 9:16 ratio)...")
  to focus_prompt. If you write your own prompt containing
  "9:16" or "Vertical", we won't duplicate it.

Example: studio_create(notebook_id="abc", artifact_type="audio", confirm=True) studio_create(notebook_id="abc", artifact_type="quiz", question_count=5, confirm=True)

Input Schema

TableJSON Schema

Name	Required	Default
`title`	No	Mind Map
`confirm`	No
`language`	No
`difficulty`	No	medium
`source_ids`	No
`description`	No
`notebook_id`	Yes
`orientation`	No	landscape
`audio_format`	No	deep_dive
`audio_length`	No	default
`detail_level`	No	standard
`focus_prompt`	No
`slide_format`	No	detailed_deck
`slide_length`	No	default
`video_format`	No	explainer
`visual_style`	No	auto_select
`artifact_type`	Yes
`custom_prompt`	No
`report_format`	No	Briefing Doc
`question_count`	No
`infographic_style`	No	auto_select
`video_style_prompt`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.7.8Sep 13, 2026

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does disclose non-obvious behavior: the human-approval gate on confirm, the default-all-sources behavior, and the subtle side effect where orientation='portrait' silently auto-prepends a TikTok 9:16 directive to focus_prompt with de-duplication. It does not say whether creation is synchronous or job-based, but the disclosed edge cases go well beyond the schema.

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?

Front-loaded with purpose followed by grouped args, type-specific options, common options and a caveat note, then examples. Given 22 parameters this length is justified, though the opening 'Unified creation tool' line restates the first sentence, and some spacing/indentation is inconsistent.

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?

For a 22-parameter tool with an output schema (so return values needn't be described), the definition covers required args, per-type options, common options, defaults, the language env-var fallback, and the slide-deck orientation workaround. Nothing an agent needs to invoke it correctly is missing.

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

Parameters5/5

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

Schema description coverage is 0% and no enums are declared in the schema, so this description is doing all the work — and it does it: every parameter is documented and the allowed values for audio_format, visual_style, infographic_style, slide_format, difficulty, report_format and the rest are enumerated here and nowhere else. This is exactly the case where the description must compensate, and it does so fully.

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?

States a specific verb and resource ('Create any NotebookLM studio artifact. Unified creation tool') and lists the nine artifact types it covers. This cleanly separates it from siblings like studio_revise, studio_status and studio_delete, which an agent can distinguish without opening any schema.

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

Usage Guidelines3/5

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

Provides usage context through the confirm gate ('Must be True after user approval') and the source_ids default ('all sources'), plus two worked examples. However, it never states when to use this vs studio_revise or studio_delete, nor under what circumstances creation should be declined, leaving the create-vs-modify routing to inference.

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