Skip to main content
Glama
Sign In
notebooklm

notebooklm

by dfelix-net
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_notebook_summary

Generates a summary of the main points from a notebook specified by ID, helping you review key content without reading every source.

Instructions

Gera um resumo com os principais pontos do caderno.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "notebook_id": "<notebook_id>"
    },
    "name": "get_notebook_summary"
  }
}

Input Schema

NameRequiredDescriptionDefault
notebook_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

C2.6/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral burden but discloses almost nothing: it does not say the operation is read-only, whether it is expensive/slow (LLM generation), whether a summary must already exist, or what language/format the summary is in. Only the bare output concept ('main points') is conveyed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence that is front-loaded and free of waste, but it is under-specified rather than genuinely concise for a generation tool; size is appropriate, content is thin.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No annotations, no output schema, and no param documentation mean the description is the only source of context, and it omits what the summary contains, how it is produced, and how it differs from generate_summary_report or ask_notebook. Incomplete for a generative tool.

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

Parameters2/5

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

One parameter (notebook_id) with 0% schema description coverage. The description merely implies the notebook is the subject via 'caderno', adding no format, ID-shape, or validity information beyond the schema's type string.

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?

States a clear verb+resource: it generates (Gera) a summary (resumo) of the notebook (caderno), and the sole parameter name notebook_id corroborates the resource. However it gives no differentiation from the overlapping sibling generate_summary_report, so an agent cannot tell which summary tool to pick.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisites (e.g. notebook must already contain sources), and no mention of the near-identical sibling generate_summary_report. The agent must guess the routing.

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

Deploy Server

Other Tools