Skip to main content
Glama

Gemini Notebook (NotebookLM) MCP Server by useapi.net (third-party)

Create a notebook

notebook_create_notebook

Create an empty notebook, optionally titled, and return its notebook id. Then add sources with notebook_add_sources (URLs, YouTube, text, Drive, Play Books) or notebook_upload_source (files). To make one Studio artifact straight from URLs or text, notebook_generate_artifact can create the notebook itself. POST /notebooks.

Input Schema

NameRequiredDescriptionDefault
emailNoThe Gemini Notebook account email. Optional when the API token has one account.
titleNoNotebook title.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is covered structurally. The description adds behavioral value beyond them by stating the notebook is created empty and that its id is returned, and by noting the alternative tool can create the notebook implicitly. It stops short of permissions or rate-limit context.

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 sentences, front-loaded with the core action and return value, followed by workflow routing. Every sentence carries distinct information; even the trailing 'POST /notebooks' is a compact endpoint pointer.

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?

There is no output schema, so the description correctly compensates by stating the return value (notebook id). Combined with the next-step routing and the annotations covering safety, an agent has everything needed to call this 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% and both parameters (email, title) are documented in the schema itself. The description only echoes the optional title ('optionally titled') and adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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 an empty notebook, optionally titled') and explicitly states the return value ('return its notebook id'). It is clearly distinguishable from sibling creation tools like notebook_generate_artifact and notebook_create_note.

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?

Names the exact follow-up tools by name and the content each handles (notebook_add_sources for URLs/YouTube/text/Drive/Play Books, notebook_upload_source for files), and gives a concrete condition for choosing the alternative route ('To make one Studio artifact straight from URLs or text, notebook_generate_artifact can create the notebook itself'). This is explicit when/when-else routing.

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