NotebookLM MCP

Check Studio artifacts

studio_status

Read-onlyIdempotent

Lists Studio artifacts in a notebook with status and download URLs. After creating an artifact, poll every 30-60 seconds to check completion by ID.

Instructions

List the notebook's Studio artifacts. Returns each one's id, type (audio, video, report, flashcards, quiz, infographic, slide_deck), status (pending, generating, completed or failed) and download_url: set for completed audio, video, infographics and slide decks (PDF), null otherwise. It lists older artifacts too: after a *_create call, poll every 30-60 seconds and find yours by its artifact_id.

Input Schema

Name	Required	Description	Default
`notebook_id`	Yes	Notebook ID, as returned by notebook_list or notebook_create

Output Schema

Name	Required	Description
`status`	Yes
`message`	No	Human-readable outcome or next step
`artifacts`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.5.0Oct 20, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "artifacts": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "download_url": {
+            "type": [
+              "string",
+              "null"
+            ]
+          },
+          "id": {
+            "description": "Artifact ID, as returned by the *_create tools",
+            "type": "string"
+          },
+          "status": {
+            "enum": [
+              "pending",
+              "generating",
+              "completed",
+              "failed"
+            ],
+            "type": "string"
+          },
+          "type": {
+            "description": "audio, video, report, flashcards, quiz, infographic, slide_deck, data_table or unknown",
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "type",
+          "status",
+          "download_url"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "message": {
+      "description": "Human-readable outcome or next step",
+      "type": "string"
+    },
+    "status": {
+      "const": "success",
+      "type": "string"
+    }
+  },
+  "required": [
+    "status",
+    "artifacts"
+  ],
+  "type": "object"
+}

Changed1 schema field changedv0.4.0Oct 20, 2026

changedInput schema / properties / notebook_id / description

Previous value: -"The notebook ID"New value: +"Notebook ID, as returned by notebook_list or notebook_create"

First observedv0.3.1Aug 6, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already cover the safe read-only, idempotent profile. The description adds important behavioral context beyond that: it lists the returned fields and their status values, specifies when download_url is populated, notes that older artifacts are also listed, and recommends a polling cadence after creation.

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?

The description is front-loaded with the core action, then adds return details and polling guidance in two compact sentences. Every sentence contributes useful information without unnecessary padding.

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 simple one-parameter list/status tool with an output schema and rich annotations, the description is complete. It covers the return shape, status lifecycle, download_url behavior, and the polling workflow after creation.

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 single notebook_id parameter is fully documented in the schema. The description adds only the implicit scoping to the notebook and does not provide meaningful new syntax or format details beyond the schema.

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 states a specific verb (List) and resource (Studio artifacts), scoped to the notebook. It clearly distinguishes this status-listing tool from the many sibling creation tools like audio_overview_create and video_overview_create.

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 gives clear usage context: after a *_create call, poll every 30-60 seconds and locate the artifact by artifact_id. It does not explicitly name alternatives or state when not to use the tool, but the polling instructions are actionable.

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