notebooklm-mcp

by brock-run

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct resource-action combination: metadata operations are clearly separated into validate/get/set/query, notebook operations into list/get/create/delete/share, and sources/audio each have their own dedicated tools. Even get_notebook and get_source are unambiguous because one returns notebook details with sources and the other returns a specific source's details.
Naming Consistency5/5
All tools follow a consistent snake_case verb_noun pattern with the notebooklm_ prefix. Action verbs such as get, set, list, create, delete, add, remove, generate, and share are used predictably across the tool set.
Tool Count5/5
14 tools is well within the ideal range for a domain-specific MCP server. The count covers notebooks, sources, metadata, sharing, and audio without feeling bloated or thin.
Completeness4/5
The tool surface provides strong lifecycle coverage for notebooks, sources, metadata, and audio overviews. Minor gaps exist such as no explicit notebook update/rename operation, no standalone list-sources tool, and no unshare or list-audio tools, but these are workable gaps rather than critical dead ends.
Average 3.1/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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 failing
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?
With no annotations, the description carries the full burden, but it only restates the creation action. It discloses no return value, created-notebook identifier, persistence behavior, idempotency, or authorization requirements.
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 single five-word sentence with no filler or redundant phrasing. It is maximally concise and front-loads the tool's purpose.
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?
Despite complete parameter schema coverage, the tool has no annotations and no output schema, so the agent is left without information about what the create operation returns or what side effects to expect. The description alone is too thin for a mutating operation.
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?
The input schema already describes both parameters (`title` and `description`) with 100% coverage, so the description does not need to add parameter semantics. It adds nothing beyond the schema, matching the baseline.
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?
The description clearly states the operation ('Create') and the resource ('a new notebook'`), so an agent can tell what the tool does. It does not explicitly name or contrast sibling tools, but the action is unambiguous among the sibling set.
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 is given for when to use this tool versus siblings like notebooklm_list_notebooks, notebooklm_get_notebook, or notebooklm_share_notebook. The intended usage is only implied by the verb 'Create', with no prerequisites, exclusions, or alternatves.
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 are provided, so the description carries the full burden of behavioral disclosure. It does communicate that the operation is destructive, but it does not state whether deletion is permanent, whether it affects the notebook or its sources, or what happens after deletion. For a deletion tool, this is a significant transparency gap.
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 extremely concise and front-loaded with the verb 'Delete', with no wasted words. However, it borders on under-specification, so it is efficient but not richly informative.
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?
For a destructive tool with no annotations, no output schema, and only a one-line description, important context is missing: the scope of deletion, irreversibility, side effects, and expected return behavior. Agents may understand the basic action but cannot fully anticipate the consequences of calling this tool.
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?
The schema already documents notebookId with 'Notebook ID' and has 100% description coverage, so the baseline is 3. The description adds no additional meaning about the parameter, such as where to find the ID or what values are valid.
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?
The description uses a specific verb ('Delete') and a specific resource ('audio overview'), so the core action is unambiguous. It is distinguishable from siblings like notebooklm_generate_audio and notebooklm_delete_notebook by resource and action, but it does not explicitly name alternatives or clarify whether it deletes all audio overviews for the notebook or a specific one.
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 guidance about when to use this tool versus alternatives such as notebooklm_remove_sources or notebooklm_delete_notebook. No context, prerequisites, or exclusions are provided, so an agent receives no help choosing or invoking the tool appropriately.
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 carries the full burden of disclosing behaviors, but it simply says 'Delete' without stating whether the deletion is permanent, whether it cascades to sources or audio, or whether any confirmation or special permissions are needed. For a destructive operation, this is a significant transparency gap.
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 extremely concise and front-loaded: 'Delete notebook(s)' communicates the essential action with no waste. It does not restate the tool name verbatim but is close to it; however, the plural and simplicity make it an efficient, appropriately sized description for a simple one-parameter tool.
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?
The description is minimally adequate for identifying the action, but it lacks important contextual information expected for a destructive tool with no annotations and no output schema. It does not mention consequences, reversibility, or scope of deletion, leaving an agent uncertain about the impact and whether any additional safeguards or confirmation steps are needed.
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?
The input schema already documents the notebookIds parameter with a description, and schema coverage is 100%, so the baseline is 3. The tool description adds no additional semantic information about the parameter beyond what the schema provides. This is acceptable when the schema is complete.
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?
'Delete notebook(s)' states a clear verb (delete) and direct object (notebook(s)), which distinguishes it from sibling tools like get, create, or list. The plural 's' hints at batch deletion, matching the array parameter. It could be more explicit about whether the deletion is permanent, but the core purpose is unambiguous.
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, no exclusions, and no prerequisites. An agent is left to infer that this is the tool for removing notebooks, but there is no mention of scenarios where another tool would be more appropriate or any state requirements.
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 provided, the description carries the full burden of behavioral disclosure. It only says 'Generate audio overview,' omitting important traits such as whether generation is asynchronous, whether pre-existing sources are required, or what resource is created. There is no contradiction with annotations because none exist.
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 a single sentence with no wasted words and front-loads the core action. It is efficient, though its brevity comes at the cost of behavioral and contextual detail.
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?
Given the absence of annotations and output schema, the description is not complete enough. It fails to mention the customization options available, any asynchronous or long-running behavior, or what the result of generation looks like, leaving an agent with insufficient context for confident invocation.
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 effectively complete: notebookId, sourceIds, episodeFocus, and languageCode all have descriptions. The description itself adds no parameter-level meaning, so it stays at the baseline for schema-covered parameters.
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?
The description states a specific verb and resource: 'Generate audio overview for a notebook.' This clearly distinguishes it from sibling tools like deleting audio or managing sources. It is less than a 5 because it does not elaborate on what an 'audio overview' is or explicitly contrast itself with any sibling.
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 is provided on when to use this tool versus alternatives, nor on prerequisites such as the notebook needing to exist or contain sources. The description simply states the action without any contextual or exclusionary information.
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 are provided, so the description carries the full burden of behavioral disclosure. 'Get' implies a read-only action, but the description does not explain what metadata is returned, whether the operation can fail for missing resources, or any authentication or access considerations.
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 a single, clear sentence with no filler or redundancy. It is appropriately front-loaded, though it could have included a brief usage hint without becoming verbose.
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?
With no output schema, no annotations, and a generic phrase like 'metadata', the description is not complete enough for an agent to know what to expect. The tool is simple, but the description still leaves notable gaps around return content, edge cases, and differentiation from the query_metadata sibling.
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?
The input schema already provides 100% parameter coverage with descriptions for both id and type, and the enum defines the accepted resource types. The description adds no parameter-specific meaning beyond what the schema provides, so the baseline score of 3 applies.
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?
The description states a clear verb ('Get') and a specific resource ('metadata for a notebook or source'), and the type enum in the schema reinforces the two target resources. It is not a tautology and is easily distinguished from set/validate metadata siblings, though it does not explicitly distinguish itself from query_metadata.
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 is given about when to use this tool versus notebooklm_query_metadata, notebooklm_validate_metadata, or notebooklm_set_metadata. The description implies a simple read operation but leaves the choice between get and query metadata entirely to inference.
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 are provided, so the description carries the full burden of behavioral disclosure. 'Get source details' implies a read-only operation, but gives no information about permissions, response shape, errors, or whether the sourceId must belong to a specific notebook. This is minimal transparency for a tool with zero annotation support.
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 single, concise sentence with no filler or redundancy. It is front-loaded with the action and resource, which is exactly what the format calls for, even if richer detail is absent.
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?
Given no output schema and no annotations, the description should provide more context about what 'source details' means, what information is returned, and any prerequisite context. The one-parameter schema is simple, but the missing behavioral and contextual information leaves the agent under-informed.
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?
The only parameter, sourceId, has a tautological description ('Source ID') and full 100% schema coverage, so the schema already documents the parameter. The description text adds no additional meaning about sourceId format, ownership, or how to obtain valid values.
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?
The description clearly identifies the action (get) and resource (source details), so an agent knows this is a retrieval operation on a source. It does not meaningfully distinguish itself from siblings like notebooklm_get_metadata or notebooklm_get_notebook, since 'details' is not elaborated.
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 is provided about when to use this tool versus alternatives. For example, there is no mention that notebooklm_get_metadata should be used for metadata retrieval, or that this returns full source details instead. The agent must infer usage entirely from the name and sibling list.
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 are provided, so the description carries the full burden of behavioral disclosure. 'Query' implies read-only, but the description does not disclose return format, pagination, filtering semantics (exact vs partial match), or behavior on no results. It is not misleading, but it is far from transparent for an agent.
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 single concise sentence with no wasted words. It front-loads the action and resource, making it quick for an agent to parse.
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?
For a tool with a nested filter object and no output schema or annotations, the description is too sparse. It lacks guidance on filter structure, result shape, and how this query differs from sibling tools, leaving significant gaps for an agent selecting and invoking the tool 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?
The input schema describes both parameters with 100% coverage: 'type' has an enum with description and 'filter' is described as 'Metadata filter'. The description adds only minimal value by confirming the filter is metadata-based, so baseline 3 is appropriate given schema coverage.
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?
The description states a specific verb ('Query'), resource ('notebooks or sources'), and search criterion ('by metadata'), so an agent can grasp the core purpose. It is somewhat distinct from sibling metadata tools because it implies searching resources by metadata rather than retrieving metadata for a resource, but it does not explicitly distinguish that behavior.
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 guidance on when to use this tool versus alternatives like notebooklm_get_metadata or notebooklm_list_notebooks. The description gives no exclusions, prerequisites, or context for choosing between metadata-related siblings. An agent would have to infer usage from the name alone.
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 carries the full burden of disclosing behavior, but only states that metadata is 'set'. It does not explain whether existing metadata is replaced or merged, whether any validation is performed, or what side effects occur. This is a significant gap for a mutating operation.
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 single, front-loaded sentence with no filler words. It conveys the core purpose efficiently without redundancy.
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?
The tool has three required parameters including a nested metadata object, no output schema, and no annotations, yet the description provides only a high-level purpose. It does not cover semantics of 'set' (merge vs. replace), metadata shape constraints, or error behavior. This leaves an agent without enough context to invoke the tool 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?
The input schema already describes all three parameters ('Resource ID', 'Type of resource', 'Metadata to set'), so schema coverage is complete. The tool description adds little beyond the schema, except confirming the type parameter selects a notebook or source. Baseline of 3 is appropriate.
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?
The description uses a specific verb ('set') and resource ('metadata') and enumerates the target resource types ('notebook or source'), making it clear what the tool does. It distinguishes from siblings such as get_metadata and query_metadata through the 'set' verb, though it does not explicitly name alternatives. Overall clear and unambiguous.
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 offers no guidance on when to choose this tool over siblings like validate_metadata or query_metadata. No conditions, prerequisites, or exclusions are provided. The only implied usage is from the verb 'set', which is not enough.
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 are provided, so the description must carry the burden of explaining behavior. 'Validate' implies a read-only check, but the description does not disclose whether invalid metadata returns a boolean, throws an error, or reports detailed validation failures. Side-effect and error behavior are completely unspecified.
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 single, four-word sentence with no filler or redundancy. It front-loads the core action and is maximally economical for the basic purpose it conveys.
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?
For a tool with no output schema and no annotations, the description leaves return values, error behavior, and the exact validation schema unspecified. It is enough to guess the general purpose but not enough to fully anticipate the tool's behavior after invocation.
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?
The only parameter, metadata, is already well described in the schema as 'Metadata to validate'. The description adds no additional meaning about allowed shape, required keys, or validation rules. With 100% schema coverage, the baseline of 3 is appropriate.
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?
The description states a specific action ('validate') applied to metadata against a schema, which distinguishes it from the sibling get/set/query metadata tools. However, it adds little beyond the tool name and does not specify which schema is used or what validation entails.
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 is provided about when to use this tool versus alternatives like notebooklm_set_metadata or notebooklm_query_metadata. It does not mention validating before setting metadata, exclusions, or any workflow 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?
With no annotations, the description carries full responsibility for behavioral disclosure. It only says 'Add sources to a notebook' and does not disclose side effects, authorization requirements, accepted source formats, duplicate handling, or whether the operation appends vs replaces.
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?
A single, direct sentence with no wasted words. The core operation is front-loaded and easy to parse.
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?
For a mutation tool with no annotations, no output schema, and no item schema for sources, ths description is too sparse. An agent does not know what a valid source entry looks like (URL, file, structured object), what constraints exist, or what the result will be.
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 baseline is 3. The description adds no meaning beyond the schema; sources and notebookId are described in only the most generic terms, but the schema at least lables them accurately.
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 a specific action (Add) and resource (sources to a notebook). The verb distinguishes it from sibling tools like remove_sources and get_source, so an agent can identify what this tool does even without inspecting the schema.
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 usage guidance is provided. The description merely restates the operation; it does not say when to prefer this tool over notebooklm_add_sources siblings, mention prerequisites, or note 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure, but it only says it gets notebook details with sources. It does not mention authentication requirements, response shape, whether sources are summarized or full, or any other 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 a single concise phrase with no filler or redundant information. It is front-loaded with the key intent and adequately sized for the simple operation.
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 one-parameter getter, the description states enough to attempt the call, but without an output schema or usage guidance it leaves the return structure and selection among sibling tools unclear. It is minimally viable but has clear gaps.
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?
The input schema has 100% coverage for the single parameter with a basic 'Notebook ID' description. The tool description adds no parameter-specific detail, so the schema already carries the meaning; baseline 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?
The description names a specific verb ('Get') and resource ('notebook details with sources'), making the operation clear. It distinguishes itself from sibling tools like list_notebooks (which lists) and get_source (which targets a single source).
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 is provided on when to use this tool versus alternatives such as notebooklm_get_metadata or notebooklm_get_source. The description does not state exclusions, prerequisites, or typical scenarios.
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 are provided, so the description carries full responsibility for disclosing behavioral traits. It only states 'Share notebook with a user' and does not mention side effects, permission requirements, idempotency, whether an invitation is sent, or what happens to existing permissions. For a mutating access-control action, this is a notable gap.
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 single clear sentence with no filler or redundant wording. It is front-loaded with the action and resource, and every word contributes to the tool's meaning.
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 share operation with all parameters documented in the schema, this is minimally viable. However, with no output schema and no annotations, the description does not disclose return behavior, failure modes, or access-control side effects, leaving some uncertainty for an agent choosing and invoking the tool.
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?
The input schema already describes all three parameters with 100% coverage, so the baseline is 3. The description adds minimal semantic value beyond confirming that the user is the share recipient; it does not further explain role meanings or format expectations, but the schema's role enum and descriptions are adequate.
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?
Describes a specific action ('Share'), resource ('notebook'), and recipient ('a user'), making the tool's core function clear. It is distinct from sibling tools like notebooklm_create_notebook and notebooklm_delete_notebook, though it does not explicitly name alternatives.
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 intended use case is implied by the verb 'Share' and the notebook/user/role parameters, so an agent can reasonably infer when to call this tool. There is no explicit guidance about when not to use it or how it compares to alternatives, but no sibling tool appears to perform sharing either, so the omission is less harmful.
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?
There are no annotations to cover safety or side effects, and the description only says 'Remove sources' without disclosing whether removal is permanent, whether it affects generated audio or other notebook content, or what state the sources enter after removal. This leaves the agent without needed behavioral context for a destructive operation.
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 single front-loaded sentence with no filler. Every word contributes to understanding the tool's purpose.
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?
For a destructive mutation with no annotations, output schema, or elaboration on side effects, this description is thin. It tells what is removed but does not say what happens afterward, whether the operation is reversible, or what an agent should expect as a result. More context would be needed for confident invocation.
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?
The input schema fully covers the sole parameter sourceIds with the description 'Source IDs to remove.' Schema coverage is 100%, so the description does not need to add much; it offers no extra semantic detail but also leaves no gap.
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 exactly what the tool does with a specific verb and resource: 'Remove sources from a notebook.' This clearly distinguishes it from sibling tools like notebooklm_add_sources and notebooklm_get_source.
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?
Usage is implied: use this when sources need to be removed from a notebook. However, there is no explicit guidance about when to choose this over alternatives, nor any caveats about prerequisites or relationships to other operations such as adding or fetching sources.
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 must carry behavioral weight. It discloses that this is a list/read operation and that results are limited to recently viewed notebooks, but it does not mention pagination defaults, ordering, result shape, or access restrictions. Some behavior is conveyed, but not deeply.
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 single, front-loaded sentence with no filler. Every word in 'List recently viewed notebooks' contributes to understanding.
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 one-parameter list call, the description is mostly adequate, but with no output schema it does not clarify what a returned notebook object looks like or what 'recently viewed' means in terms of ordering and time window. It is not severely incomplete, but has clear gaps.
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?
The input schema covers pageSize with the description 'Number of notebooks to return' (100% coverage), so the baseline is 3. The tool description adds nothing about pageSize behavior such as default or maximum values.
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 names a specific verb ('List'), a resource ('notebooks'), and a scope qualifier ('recently viewed'), making it distinct from sibling operations like get_notebook or create_notebook. This is enough for an agent to know what the tool does without opening the schema.
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 phrase 'recently viewed' provides clear context for when this tool is appropriate: a user wants their recent notebooks. It does not explicitly name alternatives or exclusions, but the sibling list makes the read/list intent obvious compared to metadata or mutation tools.
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-mcp MCP server](https://glama.ai/mcp/servers/brock-run/notebooklm-mcp/badges/card.svg)](https://glama.ai/mcp/servers/brock-run/notebooklm-mcp)

Score Badge

Copy to your README.md:

[![notebooklm-mcp MCP server](https://glama.ai/mcp/servers/brock-run/notebooklm-mcp/badges/score.svg)](https://glama.ai/mcp/servers/brock-run/notebooklm-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/brock-run/notebooklm-mcp'

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