Provides tools for document Q&A powered by Google's Gemini File Search API, allowing users to upload documents and ask questions with grounded citations.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@notebooklm-api What does the document say about refunds?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
NotebookLM-quality document Q&A — but through MCP, powered by the official Gemini File Search API.
You upload your documents. You ask a question. Every sentence in the answer cites the exact passage from your files. No hallucination, no guessing, no "I think the document says...". Just grounded answers with receipts.
Every existing NotebookLM MCP server reverse-engineers Google's internal web UI. They scrape the page with Playwright, steal cookies, and pray Google doesn't change a CSS selector. Spoiler: Google changes things. Your MCP breaks. Your Google account gets flagged.
This one uses the official Gemini File Search API. It doesn't scrape anything. It doesn't need your Google login. Just an API key from aistudio.google.com.
Related MCP server: Gemini RAG MCP Server
Upload PDFs, DOCX, TXT, HTML, or any of 80+ supported formats. Ask questions across one or multiple document stores. Get answers like this:
The maximum liability is limited to the total fees paid
in the preceding twelve months [1]. Clients must pay all
invoices within forty-five days of receipt [2].
---
Citations:
[1] Contract_A.pdf: "The maximum liability under this agreement
shall not exceed the total fees paid in the preceding
twelve (12) months." (confidence: 92%)
[2] Contract_A.pdf: "The Client shall pay all invoices within
forty-five (45) days of receipt." (confidence: 88%)Every [1], [2] maps to the exact passage from your document. Not a summary. The actual text.
# Set your Gemini API key
export GEMINI_API_KEY=your-key-from-aistudio.google.com
# Add to Claude Code
claude mcp add notebooklm-api npx @mcpware/notebooklm-api
# Or add to Claude Desktop (~/.claude/mcp.json)
{
"mcpServers": {
"notebooklm-api": {
"command": "npx",
"args": ["@mcpware/notebooklm-api"],
"env": { "GEMINI_API_KEY": "your-key" }
}
}
}Then just talk to Claude naturally. The three-step workflow:
Step 1: Create a store (one time per topic)
"Create a store called 'Legal Docs'"
Step 2: Upload your files (one time per topic)
"Upload all PDFs from ~/contracts/ to the Legal Docs store"
Step 3: Ask questions (as many as you want)
"What are the liability clauses across all contracts?" "Which contract has the shortest termination notice period?" "Does any contract mention non-compete?"
Claude calls create_store, upload_document, and ask automatically. You don't need to know store names or API details. Each store is independent, so you can have separate stores for different topics (legal docs, tax records, research papers, etc.) and query them individually or together.
Tool | What it does |
| Create a document store |
| List all stores |
| Upload a file (PDF, DOCX, TXT, etc.) to a store. Waits for indexing to finish. |
| List documents in a store |
| Ask a question. Returns answer with per-passage citations. |
| Remove a document |
| Remove a store |
When you call ask, the Gemini File Search API does three things:
Searches your uploaded documents for relevant passages (vector similarity, not keyword match)
Generates an answer grounded in those passages
Returns groundingSupports — a map from each sentence in the answer to the exact source passage
We parse that map into inline [1], [2] markers and a citation list. This is the part every competitor gets wrong — they dump the raw API response without parsing it. We give you something you can actually read and verify.
You should, if the web UI works for you. This tool is for when you want:
Document Q&A inside your coding agent (Claude Code, Cursor, etc.)
Programmatic access — upload 100 documents, ask 50 questions, extract structured data
Stability — no browser automation, no cookies, no scraping
Your own API key — you control the cost and the data
On the free tier, Google may use your data to improve products. On the paid tier (link a billing account), they don't. If your documents are sensitive, use the paid tier. Details.
Go to aistudio.google.com
Click "Get API key"
Set it as GEMINI_API_KEY
The free tier gives you enough to try everything. Paid tier for production use.
MIT
Ask a question about your documents. Returns an answer with per-passage citations mapping every claim to its source document and exact passage. This is the core tool — use it after uploading documents to a store.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Gemini model to use (default: gemini-2.5-flash) | |
| question | Yes | Your question about the documents | |
| store_names | Yes | One or more store resource names to search across |
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.
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.
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.
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.
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.
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.
Create a new document store for uploading and searching files.
| Name | Required | Description | Default |
|---|---|---|---|
| display_name | No | Human-readable name for the store (e.g. "Legal Documents Q1") |
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.
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.
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.
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.
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.
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.
Delete a document from a store.
| Name | Required | Description | Default |
|---|---|---|---|
| document_name | Yes | Document resource name (from list_documents) |
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.
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.
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.
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.
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.
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.
Delete a store and optionally all its documents.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | Delete even if documents remain (default: false) | |
| store_name | Yes | Store resource name |
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.
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.
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.
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.
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.
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.
List all documents in a store.
| Name | Required | Description | Default |
|---|---|---|---|
| store_name | Yes | Store resource name |
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.
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.
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.
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.
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.
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.
List all document stores.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Upload a document to a store. Supports PDF, DOCX, TXT, HTML, CSV, and more. Waits for processing to complete before returning.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to the file on disk | |
| store_name | Yes | Store resource name (from create_store) | |
| display_name | No | Display name for the document (defaults to filename) |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.1askcreate_storedelete_documentdelete_storelist_documentslist_storesupload_documentEach 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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Ingest, manage, and retrieve documents for RAG-powered AI applications
Securely search and manage workspace context files for AI agents and teams.
Search and reason over your Obsidian-style Markdown vault, right from ChatGPT.
Turn documents into structured, AI-ready data by parsing, enriching, chunking, and embedding.
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
