notebooklm-api

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation5/5
Each tool targets a distinct resource action: store creation/listing/deletion, document upload/listing/deletion, and question answering. The 'ask' tool is clearly separated from file management operations, so an agent should not confuse any two tools.
Naming Consistency4/5
Most tools follow a clear verb_noun snake_case pattern (create_store, list_documents, delete_document). The plural forms in list_stores/list_documents and the bare-verb 'ask' are minor deviations, but they do not undermine readability.
Tool Count5/5
Seven tools is a well-scoped size for this document Q&A server. Each tool covers a necessary part of the workflow without redundancy or bloat.
Completeness4/5
The store and document lifecycles are mostly covered: create, list, delete, and upload, plus the core ask/search capability. The only noticeable gaps are update/replace operations and a simple get-document detail operation, but these are not critical for the intended workflow.
Average 3.7/5 across 7 of 7 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 status not available
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.
This repository includes a glama.json configuration file.
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 are provided, so the description carries the full burden of behavioral disclosure. It does not mention whether the operation is read-only, whether results are paginated, what fields are returned, or any authentication or scoping constraints beyond the store name. The word 'List' implies a read operation, but no behavioral detail is added.
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, efficient sentence with no wasted words. The core action and resource are front-loaded, and the store scoping is immediately clear.
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 single parameter, no nested objects, and no output schema, the description is minimally viable but leaves clear gaps. It does not explain what a returned document looks like, whether the list includes metadata or full content, or how errors such as a nonexistent store are handled. An agent could call it correctly, but would lack important 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 description coverage is 100% for the single parameter, and the schema already describes store_name as 'Store resource name'. The description adds no additional meaning to the parameter beyond what the schema provides, which is acceptable at baseline given full coverage.
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 ('List') on a specific resource ('documents') scoped to a store. It is not a tautology and distinguishes itself from sibling tools like list_stores by specifying documents rather than stores.
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 gives no guidance on when to use this tool versus alternatives such as upload_document, delete_document, or ask. There is no mention of intended use cases, exclusions, or relationships to sibling tools, leaving the agent 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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only states that a store is created; it does not cover what happens when display_name is omitted, whether creation is idempotent, permissions needed, or what the response contains.
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 one succinct sentence with no filler. The core action and purpose are front-loaded, making it instantly understandable.
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?
The description is adequate for a simple creation tool, but it does not mention whether the call returns a store ID or how the result connects to siblings like upload_document and ask. In an annotation-free context, those gaps are noticeable.
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 fully describes display_name with a useful human-readable example, so schema coverage is 100%. The description adds no additional parameter-level meaning, making the baseline of 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Create') and resource ('document store') and clarifies its purpose ('for uploading and searching files'). This clearly differentiates it from siblings like delete_store and list_stores.
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 that creating a store is a prerequisite for uploading files, but it never explicitly states when to use this tool or mentions alternatives. No exclusion conditions or sibling routing is provided.
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 behavioral disclosure. It hints at document deletion but does not state that deleting a store is destructive and likely irreversible, that deletion may be refused when documents remain without force, or what actually happens to documents when force is true. The schema's force description provides some clarity, but the tool description itself leaves critical behavior implicit.
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 redundant phrasing. It communicates the core action and an important optional behavior efficiently, and the key resource is front-loaded.
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 tool with no annotations and no output schema, the description is too sparse. It omits failure semantics, the default refusal when documents remain, irreversibility, and any prerequisites such as the store needing to exist. The basic call shape is present, but an agent is left without enough behavioral context to safely invoke this 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 description coverage is 100%, so the baseline is 3. The description adds value by clarifying that deleting the store can also delete its documents, which maps to the force parameter's meaning. This goes slightly beyond what the schema alone states, so a 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Delete a store.' The additional phrase 'and optionally all its documents' adds scope and clearly distinguishes this from the sibling delete_document tool. An agent can determine what resource this operates on 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the tool name and resource: use this to delete a store, while delete_document exists for individual documents. However, there is no explicit guidance about when force should be used, when deletion will fail, or when to prefer this over other siblings. The guidance is functional but not explicit.
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 present, the description carries the full burden of disclosing behavior, but it only says 'List all document stores'. It does not mention whether the operation is read-only, if authentication is required, what the output looks like, or whether pagination or access restrictions apply.
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, focused sentence with no redundant words. The verb and object are immediately clear, making it highly scannable for an agent.
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 zero-parameter list operation, the description covers the core intent adequately. However, with no output schema, adding a note about the return format (e.g., an array of store identifiers or metadata) would make it fully self-contained; the gap is minor given the tool's simplicity.
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?
The input schema is empty with zero parameters, so the baseline of 4 applies. There is no parameter information for the description to enrich, and no additional explanation is needed.
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 action 'List' and the specific resource 'document stores', making the tool's purpose unmistakable. The resource term 'stores' distinguishes it from document-level operations like list_documents, even without explicitly naming siblings.
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 choose this tool over alternatives such as list_documents or create_store. There is no mention of prerequisites, filtering, or typical use cases, leaving the agent to infer the appropriate 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 are provided, so the description must carry the burden of behavioral disclosure. It only says 'Delete' and does not state whether deletion is permanent, requires special permissions, or has side effects on related resources.
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 short sentence with the action front-loaded ('Delete a document from a store'). Every word contributes, with no filler or redundancy.
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 deletion tool, the description and schema cover the basic mechanics of invocation. However, because annotations are absent, the lack of behavioral context such as irreversibility or side effects leaves a gap that matters for a destructive 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?
Schema coverage is 100%, and the parameter description already provides provenance ('from list_documents'), so the description does not need to add much. It adds minimal context by specifying the document is deleted from a store, but no new parameter semantics are provided.
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 a specific verb ('Delete') and a specific resource ('document from a store'), clearly distinguishing this tool from siblings like upload_document and delete_store. It states exactly what the tool does without 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?
The description gives clear context for when to use the tool: removing a document from a store. The schema's 'from list_documents' hint further implies the prerequisite step of listing documents, though alternatives are not explicitly named.
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?
Without annotations, the description carries the disclosure burden. It usefully reveals that uploads are synchronous by saying 'Waits for processing to complete before returning,' but it does not disclose failure behavior, overwrite semantics, size limits, or what the response contains.
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 concise sentences deliver the core action, supported formats, and a key behavioral guarantee with no filler. The most important information is front-loaded in the first sentence.
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 tool with no annotations and no output schema, the description is somewhat thin: it omits return value, prerequisite store existence, and error conditions. The synchronous processing note helps, but an agent is left guessing about what happens after a successful upload.
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 input schema already documents all three parameters. The description adds format support context tied to file_path but does not materially enrich parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Upload a document to a store') with a clear resource and target. It also enumerates supported formats, which distinguishes it from sibling tools like create_store or list_documents.
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 usage through 'Upload a document to a store' and the schema notes store_name comes from create_store, but there is no explicit guidance on when to use this tool versus alternatives, nor any prerequisite or follow-up steps.
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 provided, the description carries the full burden and does disclose a key non-obvious behavior: every claim in the answer is mapped to its source document and exact passage via per-passage citations. It does not cover error cases, auth requirements, or rate limits, but the core behavioral contract is clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with no filler. The primary action is front-loaded, followed by the distinct return-behavior detail, then the usage condition. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-parameter tool with a fully described schema, the description covers what it does, what it returns, and when to use it. Nothing essential is missing for an agent to select and invoke this tool correctly. The corrupted context-signal text is external noise and does not affect the tool definition's completeness.
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 100% — all three parameters (model, question, store_names) have descriptions and defaults where applicable. The description adds little parameter-level meaning beyond the schema, only the contextual precondition that documents should already be uploaded to a store. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Ask a question about your documents.' It also specifies the return format — 'an answer with per-passage citations mapping every claim to its source document and exact passage' — making the tool's function unambiguous and distinct from generic search or listing tools.
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 gives clear usage context: 'This is the core tool — use it after uploading documents to a store.' This tells the agent when in the workflow to invoke it. It does not explicitly name alternatives or exclusion conditions, but none are provided in the sibling context.
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-api MCP server](https://glama.ai/mcp/servers/mcpware/notebooklm-api/badges/card.svg)](https://glama.ai/mcp/servers/mcpware/notebooklm-api)

Score Badge

Copy to your README.md:

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

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/mcpware/notebooklm-api'

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