notebooklm-py-diet-mcp

by earlyprototype

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Tools generally have distinct purposes, but generate_and_download and export_artifact both deal with artifacts, and list_sources vs list_artifacts could be confused. Most tools are clearly separated.
Naming Consistency3/5
Most tools follow a verb_noun pattern, but there are inconsistencies like 'list_notebooks_tool' with a '_tool' suffix, 'research_and_import' uses 'and', and 'pdf_to_png' lacks a verb. Overall patterns are mixed.
Tool Count5/5
14 tools is well-scoped for a NotebookLM server, covering notebook management, sources, Q&A, artifacts, accounts, and PDF utilities. No obvious bloat or deficiency.
Completeness4/5
Core workflows (create/list notebooks, add sources, ask questions, generate/export artifacts, account management) are covered. Minor gaps like missing delete/update operations do not significantly hinder typical use.
Average 3.9/5 across 14 of 14 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only states the action 'list all sources' without disclosing if it's read-only, rate limits, or any side effects. The behavioral transparency is minimal.
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?
The description is short and front-loaded with the main action. The docstring format is somewhat redundant with the schema, but overall it is efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one parameter, the description covers the basic purpose and parameter. However, it lacks details about the return format (no output schema) and any behavioral aspects like sorting or filtering. It is minimally complete but has gaps.
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?
Schema description coverage is 0%, so the description should add meaning. The docstring says 'notebook_id: ID of the notebook' which adds basic text but no format, constraints, or examples. This is redundant with the schema title 'Notebook Id', adding very little value.
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 clearly states the tool lists all sources in a notebook. It uses a specific verb 'list' and resource 'sources' with clear scope. This distinguishes it from sibling tools like list_notebooks_tool and add_sources.
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?
No guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or context for usage. The description only states the action without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. Mentions starting a research task, polling, and auto-importing, but does not detail side effects, error handling, or what 'top results' means. Lacks depth for a multi-step tool.
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?
Description is concise with two paragraphs; first clearly states purpose, then args/returns listed. No fluff, but could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers workflow and basic parameter explanations, but lacks details on failure modes, timeout behavior, and full return structure. With no output schema, agents may need more context.
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 coverage is 0%, so description must add meaning. It lists parameters with brief meanings (e.g., 'Where to search: web or drive' for source, 'Maximum number of results' for max_results). Useful but not highly detailed.
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 clearly states it research a topic and imports results as notebook sources in a single call. It distinguishes from siblings like 'ask_question' (answer without import) and 'add_sources' (import only).
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?
Implies usage when wanting to combine research and import in one step, but no explicit when-to-use, when-not, or alternatives mentioned. Sibling tools hint at alternatives but description lacks direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It only notes that 'persona' and 'response_length' are cleared if empty, but omits side effects (e.g., state changes), authentication needs, rate limits, or costs. The impact of asking a question on the notebook or account is unclear.
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 a well-structured docstring of about 10 lines. It immediately states the purpose, then lists parameters with clear explanations, and finally mentions the return type. Every sentence adds value, and there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no output schema, no annotations), the description covers inputs adequately but lacks details on return structure beyond 'Dictionary with the answer and citation information'. It does not explain possible errors, response format specifics, or how to interpret citations, which would be helpful for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description explains all 6 parameters: notebook_id, question, source_ids (comma-separated), conversation_id (thread continuation), persona (descriptive role), and response_length (short/medium/long). It adds semantics missing from the schema, such as format and behavior when empty.
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 begins with a clear statement: 'Ask a question to a NotebookLM notebook and get an AI-generated answer.' It specifies the action (ask), the resource (NotebookLM notebook), and the result (AI-generated answer). This is distinct from sibling tools that perform other operations like listing, creating, or exporting.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical scenarios, or when not to use it. Sibling tools like research_and_import or list_sources are not differentiated, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose behavioral traits such as side effects, permissions, idempotency, or constraints (e.g., title uniqueness). Only states creation action and return value.
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 short and well-structured, with a clear purpose line followed by args and returns in a clean format. No unnecessary words.
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?
Given the simplicity of the tool (one parameter, no output schema), the description covers basic purpose and return. Could add more on constraints like title length or uniqueness, but is adequate for its complexity.
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 coverage is 0%, but the description adds meaning by explaining the parameter's purpose ('Title for the new notebook'), which helps beyond the schema's type and title alone. However, no details on format or validation.
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?
Clearly states it creates a new NotebookLM notebook with a specific verb and resource. Distinguishes from sibling list_notebooks_tool by nature of operation (creation vs listing).
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?
Implied usage for creating a notebook, but no explicit guidance on when to use this vs alternatives like list_notebooks_tool or other tools. No exclusion criteria mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states return type ('dictionary'). Lacks details on authorization, rate limits, side effects, or performance. Bare minimum behavioral info.
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?
Concise single-sentence purpose followed by structured parameter docs. No redundancy, front-loaded. Every sentence adds value.
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 output schema and description only says 'dictionary with list of artifacts'. Missing details on response structure, pagination, ordering, or error cases. Incomplete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but description explains notebook_id as ID and artifact_type with concrete allowed values. Adds useful meaning beyond property names.
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?
Description clearly states action ('List artifacts') and resource ('in a notebook') with optional filtering. Distinguishes from sibling tools like list_notebooks and list_sources by specifying artifacts.
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?
Implies usage for listing artifacts filtered by type, but no explicit when-to-use, when-not-to-use, or alternative tools. User must infer context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It explains that the tool performs both generation and download atomically, and details parameter behaviors (e.g., extension requirements, optional instructions for slide decks). However, it omits key traits like error handling, network dependency, file overwrite behavior, or authentication requirements, leaving the agent with gaps.
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?
The description is well-structured: first line states purpose, followed by supported types, then parameter details in a clear bullet-like list. It is sufficiently detailed without being redundant, though some parameter descriptions could be slightly tightened (e.g., repeating 'audio' for format/length).
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?
Given the tool's complexity (9 parameters, no annotations, no output schema), the description covers all parameters, return type (dictionary with status), and supported types with extension guidance. It lacks details on error conditions and the exact structure of the return dictionary, but for a generation + download tool, it provides adequate information for an agent to invoke it correctly.
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%, so the description must fully compensate. It does so by providing detailed explanations for all 9 parameters, including extension mappings for output_path, the purpose of instructions (especially for slide decks), and options for audio and quiz parameters. This adds significant meaning beyond the bare parameter names and types.
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 clearly states the tool's purpose with a specific verb+resource: 'Generate an artifact and download it in a single call.' It lists supported artifact types (report, audio, slide_deck, quiz, infographic), clearly distinguishing from siblings like 'list_artifacts' (which just lists) and 'export_artifact' (which likely exports existing artifacts without generation).
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?
The description provides no guidance on when to use this tool versus alternatives (e.g., 'export_artifact'). It does not mention prerequisites, edge cases, or scenarios where this tool is preferred over others. The usage context is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only states the return format but does not disclose potential limitations, pagination, or required permissions. For a list operation, minimal behavioral info is given.
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 sentences, front-loaded with the purpose. No unnecessary words.
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?
For a simple list operation with no parameters, the description adequately states the resource and return format. It could mention ordering or if the list is complete, but it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema coverage is 100%. The description does not need to add parameter semantics, so the baseline of 4 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?
The description uses the verb 'List' and specifies the resource 'all NotebookLM notebooks', making it distinct from sibling tools like create_notebook or list_sources.
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?
No guidance on when to use this tool versus alternatives. It is implied that this is for retrieving all notebooks, but no explicit comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that sources are added, that a 'wait' parameter controls synchronous behavior, and that results are returned. However, it does not describe potential side effects (e.g., overwriting, idempotency), authentication needs, rate limits, or error handling. The behavioral profile is partially clear but lacks important safety and operational details.
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?
The description is well-structured with a purpose statement, a list of supported types, and an argument section with examples. It is front-loaded with the main action. The 'Args' section adds some redundancy but is helpful for readability. It is slightly verbose but every part serves a purpose, earning a high score without being perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions 'Dictionary with results for each source' but omits details on error handling, idempotency, or whether sources are appended or replace existing ones. Parameters are well-covered, but the tool's overall behavior (e.g., required notebook existence, limits on number of sources) is not addressed. Siblings are not cross-referenced. Adequate but lacking for a mutation tool.
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%, so the description must compensate entirely. It does so excellently: each parameter is explained with types and examples. 'sources' is detailed with a JSON array example showing structure ('type', 'value', 'title' for text). 'wait' is clarified as a boolean for processing. This adds significant meaning beyond the bare schema titles and types.
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 clearly states the tool's purpose: 'Add multiple sources to a notebook in a single call.' It specifies the verb 'add', the resource 'sources to a notebook', and highlights batching with 'single call'. This distinguishes it from sibling tools like 'list_sources' (read-only) or 'research_and_import' (different function). Supported types are listed, adding specificity.
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?
The description explains what the tool does but provides no explicit guidance on when to use it versus alternatives. It does not mention when not to use it, prerequisites (e.g., notebook must exist), or compare with related tools. The context of adding multiple sources is implied but not framed against single-add options or other import methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the return value but does not explicitly state that the tool has no side effects (read-only). For a simple info tool, this is adequate but could be more transparent.
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 two sentences, concise, and front-loaded. Every word adds value, and it efficiently communicates the tool's output without extraneous detail.
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?
Given no parameters, no output schema, and a simple read-only purpose, the description fully explains what the tool does and returns. It is sufficient for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description needs to add no additional meaning. The baseline for 0 parameters is 4, and the description correctly focuses on the tool's purpose and output.
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 clearly states the tool shows the current account and available profiles. It uses a specific verb 'Show' and identifies the resource (account info), which distinguishes it from siblings like switch_account and create_profile.
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?
The description implies use for viewing info but provides no explicit guidance on when to use this tool versus siblings or when not to use it. For a tool in a set with many action-oriented siblings, additional context would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals key behaviors: it opens a browser for Google sign-in, stores the profile at a specific path, and requires authentication. No annotations exist, so the description carries full burden; it provides substantial behavioral 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?
The description is concise with a front-loaded main action, followed by a clear Args section and a Returns note. Every sentence is informative without unnecessary detail.
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?
The description covers the purpose, parameter, process, and outcome. However, the return format is vague ('status and next steps') and prerequisites (like whether a user can have multiple profiles) are not mentioned. It is mostly complete for a low-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning by giving examples ('work', 'design', 'testing') and explaining the storage path. This compensates well for the lack of schema descriptions.
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 clearly states it creates a new NotebookLM account profile and launches Google login. The verb 'create' and resource 'profile' are specific, and it distinguishes from sibling tools like 'switch_account' which assumes an existing profile.
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?
The description implies this tool is used for setting up a new profile before switching, but it does not explicitly state when not to use it or compare with alternatives. The mention of 'use via switch_account' provides some workflow guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions behavioral adaptation ('Uses the appropriate export method based on the artifact type') and default format handling, but lacks depth on permissions, side effects, or error conditions.
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 concise with a clear first sentence, bullet-pointed Args, and Returns section. Every sentence is informative and efficient.
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?
For a 4-parameter tool with no annotations or output schema, the description covers purpose, parameters, and return type. It lacks mention of file overwrite behavior or async nature, but is largely complete.
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%, but the description fully explains each parameter (notebook_id, artifact_id, output_path, export_format) with clear purpose and examples (pdf, csv, json). This adds significant meaning 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 clearly states 'Export an artifact to a file in the requested format.' It uses specific verb+resource and distinguishes from siblings like list_notebooks or create_notebook.
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 explains that the tool uses the appropriate export method based on artifact type, providing clear context. However, it does not explicitly exclude alternatives or specify when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses default output path, sorting, and return dictionary. Does not mention potential overwriting, supported image sizes, or error conditions. Adequate but not exhaustive.
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?
Structured with clear sections (args, returns). Uses bullet points for readability. Every sentence adds value without redundancy. No unnecessary fluff.
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?
Covers input options, output default, sorting, and return value. With 3 parameters and no output schema, description is mostly complete. Minor gaps: no mention of file size limits, overwrite behavior, or error handling.
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%, so description must compensate. It explains all three parameters: image_paths (comma-separated or JSON array), image_directory (alternative input), output_path (default behavior). Adds concrete formatting and usage details absent from 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?
Clearly states the action (Combine), resource (PNG images), and output (single PDF). Distinguishes from sibling tool pdf_to_png by specifying input format and output format. No ambiguity.
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?
Provides explicit guidance on using image_paths vs image_directory, including sorting behavior and naming convention. Lacks explicit when-not-to-use but covers main usage scenarios. No direct comparison with siblings beyond context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the change takes effect immediately and is persisted across server restarts. While no annotations are provided, this covers key behavioral aspects. It does not mention potential side effects like losing unsaved work or requiring re-authentication.
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 well-structured with separate paragraphs for purpose, usage, and argument details. Every sentence is informative, and there is no redundancy or wasted text.
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?
For a tool with one required parameter and no output schema, the description adequately explains what the tool does, how to use it, and what to expect in return (dictionary confirming switch). Minor gaps exist (e.g., error handling for invalid profile), but overall it is complete.
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?
With 0% schema description coverage, the description adds essential meaning. It provides examples (e.g., 'work', 'personal', 'design') and explains the naming convention (~/.notebooklm-<name>), going beyond the schema's simple string type.
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 clearly states the verb 'Switch' and the resource 'active NotebookLM account to a different Google profile.' It distinguishes from siblings like get_account_info (which shows profiles) and create_profile (which creates new profiles).
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?
The description advises using get_account_info to see available profiles before switching, providing clear context. However, it does not explicitly state when not to use the tool or list all alternative actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden for behavioral disclosure. It explains the conversion process, default output directory naming, and return value structure. It could mention side effects like file overwriting or required permissions, but the current level is adequate.
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 concise at about 6 sentences plus structured Args and Returns. It is front-loaded with the purpose and every sentence serves a clear function without redundancy.
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?
Given the tool has 3 parameters, no output schema, and no annotations, the description covers purpose, use case, parameter details, and return format completely. An agent can understand when and how to invoke it correctly.
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%, so the description must compensate. It explains that pdf_path is the source file, output_directory defaults to a folder beside the PDF named <filename>_pages/, and dpi defaults to 200 with a quality-size balance, adding significant meaning beyond the schema's type and defaults.
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?
Description clearly states 'Convert a PDF file to individual PNG images (one per page).' This is a specific verb+resource combination that differentiates it from the sibling tool 'png_to_pdf' which performs the reverse operation.
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?
The description says 'Useful for making slide deck pages visible to LLMs for review or editing.' This provides clear context for when to use the tool. No explicit when-not or alternative tools are mentioned, but the sibling list implies the reverse operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![notebooklm-py-diet-mcp MCP server](https://glama.ai/mcp/servers/earlyprototype/notebooklm-py-diet-mcp/badges/card.svg)](https://glama.ai/mcp/servers/earlyprototype/notebooklm-py-diet-mcp)

Score Badge

Copy to your README.md:

[![notebooklm-py-diet-mcp MCP server](https://glama.ai/mcp/servers/earlyprototype/notebooklm-py-diet-mcp/badges/score.svg)](https://glama.ai/mcp/servers/earlyprototype/notebooklm-py-diet-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/earlyprototype/notebooklm-py-diet-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server