Provides tools to manage file search stores, upload documents, import files, and perform RAG queries using Google's Gemini models.
Click on "Deploy 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., "@gemini-file-search-rag-mcp query my store for the executive summary of Q4 earnings"
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.
MCP (Model Context Protocol) server for Google's Gemini File Search (RAG). Manage file search stores, upload documents, and query with RAG through 12 tools.
Works with Claude Desktop, Cursor, VS Code, and any MCP client.
Add to claude_desktop_config.json:
{
"mcpServers": {
"gemini-rag": {
"command": "npx",
"args": ["-y", "@node2flow/gemini-file-search-rag-mcp"],
"env": {
"GEMINI_API_KEY": "your-gemini-api-key"
}
}
}
}Add to MCP settings:
{
"mcpServers": {
"gemini-rag": {
"command": "npx",
"args": ["-y", "@node2flow/gemini-file-search-rag-mcp"],
"env": {
"GEMINI_API_KEY": "your-gemini-api-key"
}
}
}
}For remote deployment or shared access:
GEMINI_API_KEY=your_key npx @node2flow/gemini-file-search-rag-mcp --httpServer starts on port 3000 (configurable via PORT env var). MCP endpoint: http://localhost:3000/mcp
Related MCP server: estudIA-MCP
Environment Variable | Required | Description |
| Yes | Google Gemini API key (get one here) |
| No | Port for HTTP server (default: |
Tool | Description |
| Create a new file search store |
| List all file search stores |
| Get store details |
| Delete a store (with optional force) |
Tool | Description |
| Upload content directly to a store (text, base64) |
| Import an existing Gemini file into a store |
Tool | Description |
| Check status of a store operation |
| Check status of an upload operation |
Tool | Description |
| List documents in a store |
| Get document details |
| Delete a document from a store |
Tool | Description |
| Query documents using RAG with Gemini models |
Node.js 18+
Google Gemini API key
Go to Google AI Studio
Click "Create API key"
Copy the key and use it as GEMINI_API_KEY
git clone https://github.com/node2flow-th/gemini-files-search-rag-mcp-community.git
cd gemini-files-search-rag-mcp-community
npm install
npm run build
# Run in stdio mode
GEMINI_API_KEY=your_key npm start
# Run in dev mode (hot reload)
GEMINI_API_KEY=your_key npm run dev
# Run in HTTP mode
GEMINI_API_KEY=your_key npm start -- --httpMIT License - see LICENSE
Copyright (c) 2026 Node2Flow
Create a new Gemini File Search store for RAG documents. Returns the created store resource. Use this to create a knowledge base before uploading documents.
| Name | Required | Description | Default |
|---|---|---|---|
| display_name | Yes | Display name for the store (max 512 characters) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that it returns the created store resource and acts as the prerequisite for uploads, but says nothing about naming constraints, quotas, or failure behavior. Given the annotation coverage, this modest addition merits a 3.
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 that front-load what is created, then what is returned, then when to use it. No sentence is redundant and nothing is buried.
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 single-parameter create tool with annotations covering safety and no output schema, the description tells the agent what it makes, what it returns, and when to reach for it. The only gap is not naming the downstream upload sibling explicitly.
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% with a single parameter, so the schema already documents display_name and its 512-character limit. The description adds no parameter-level detail beyond that, so the baseline 3 applies.
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?
States a specific verb and resource ('Create a new Gemini File Search store for RAG documents') and clarifies the returned artifact. It does not explicitly distinguish itself from siblings like gemini_delete_store or gemini_list_stores, but the create verb makes the intent unmistakable.
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?
'Use this to create a knowledge base before uploading documents' gives a clear sequence and prerequisite, pointing at the upload flow. It stops short of naming the sibling tools (e.g., gemini_upload_to_store) explicitly, so an agent must infer the next step from the sibling list.
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 File Search store. Use force=true to also delete associated chunks.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | If true, also delete associated chunks | |
| document_name | Yes | Document resource name, e.g. "fileSearchStores/abc123/documents/doc456" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare destructiveHint=true and readOnlyHint=false, so the agent knows this is a destructive write operation. The description adds the behavioral note that force=true also deletes associated chunks, which is important context beyond annotations. It doesn't cover permissions or irreversibility, but with annotations covering the safety profile, this is solid.
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 sentences, zero waste, front-loaded with the primary action and followed by the key optional parameter behavior. Perfectly sized for the tool's complexity.
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 tool's simplicity (2 params, no output schema, clear annotations), the description covers purpose and the force behavior. It could mention that deletion is irreversible or what happens if the document doesn't exist, but it is largely complete for correct invocation.
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%, so both parameters are fully documented in the schema. The description repeats the force parameter semantics (also delete associated chunks) and doesn't add new meaning beyond the schema. Baseline 3 is appropriate when schema does the heavy lifting.
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 (Delete) and resource (a document from a File Search store), clearly distinguishing it from sibling tools like gemini_delete_store (which deletes a store) and gemini_get_document. An agent can immediately understand the operation.
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?
It gives clear guidance on when to use the force parameter, explaining that force=true deletes associated chunks. However, it does not explicitly state when to use this tool versus alternatives like gemini_delete_store or provide conditions for deletion (e.g., prerequisites).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a Gemini File Search store. Use force=true to also delete all documents inside it.
| Name | Required | Description | Default |
|---|---|---|---|
| force | No | If true, cascade delete all documents in the store | |
| store_name | Yes | Store resource name, e.g. "fileSearchStores/abc123" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the description doesn't need to restate the destructive nature. It adds the critical behavioral detail that force=true cascades to delete all documents inside the store, which is not conveyed by annotations. However, it doesn't mention irreversibility, permission requirements, or failure modes for non-empty stores.
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 sentences, zero waste. The first states the core action, the second immediately clarifies the optional force parameter. Front-loaded and efficient.
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 two-parameter delete tool with full schema coverage and annotations covering the safety profile, the description is nearly complete. It covers the core action and the force cascade. Minor gaps: no mention of irreversible data loss or what happens if force is false and documents exist, but these are not critical given the destructiveHint annotation.
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%, with both parameters fully described in the schema (force's cascade behavior is already documented there). The description repeats the force behavior but adds no syntax, format, or validation details beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.
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?
States a specific verb (Delete) and resource (Gemini File Search store), clearly distinguishing from siblings like gemini_list_stores or gemini_get_store. It doesn't explicitly contrast with gemini_delete_document, but the resource specificity makes the target unambiguous.
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 explains the force parameter's effect (cascade delete), which implies usage conditions, but provides no explicit when-to-use vs. alternatives guidance (e.g., when to use gemini_delete_document instead). Context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific document in a File Search store, including state, size, and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| document_name | Yes | Document resource name, e.g. "fileSearchStores/abc123/documents/doc456" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds what fields are returned (state, size, metadata), which is useful, but does not cover error behavior or missing-document handling.
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?
A single efficient sentence listing the key returned fields. No waste, but also no front-loaded caveats or differentiation.
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 read-only getter with one fully documented parameter and annotations covering safety, the description is adequate. It does not mention what happens on invalid names or whether the store must exist, but these are minor gaps.
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 document_name parameter is fully documented in the schema with a format example. The description adds no additional parameter meaning beyond what the schema provides. 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?
States a specific verb and resource: get a specific document in a File Search store. It clearly distinguishes retrieval by name from sibling list_documents and get_store, though it does not name any sibling explicitly.
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 on when to use this versus gemini_list_documents or gemini_get_store. The phrase 'specific document' implies retrieval by name, but no explicit context or exclusions are offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of a store operation (create, delete, import). Returns whether the operation is done and any error details.
| Name | Required | Description | Default |
|---|---|---|---|
| operation_name | Yes | Operation resource name, e.g. "fileSearchStores/abc123/operations/op456" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds value by stating what the response contains — a done flag and any error details — which is behavior beyond the annotations.
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 tight sentences with zero waste; the core purpose is front-loaded and the return-value note follows immediately. Nothing is redundant or padded.
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?
With no output schema, the description must convey what comes back, and it does so briefly (completion state plus error details). For a single-parameter, read-only status check this is nearly complete, though it omits any note on polling cadence or operation expiry.
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% for the single operation_name parameter, and the schema even supplies a concrete example resource path. The description adds no additional meaning beyond that, so the baseline of 3 applies.
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 names a specific verb ("Check the status") and resource ("a store operation"), and enumerates the operation kinds it covers (create, delete, import). This distinguishes it reasonably well from the sibling gemini_get_upload_operation, though the separation is by implication rather than explicit contrast.
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 is implied: an agent can infer this is used to poll the status of an operation kicked off by create/delete/import. However, there is no explicit statement of when to call it (e.g., after a long-running create/import) and no mention of the upload-operation alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific Gemini File Search store by its resource name.
| Name | Required | Description | Default |
|---|---|---|---|
| store_name | Yes | Store resource name, e.g. "fileSearchStores/abc123" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered without the description's help. The description adds no extra behavior such as what happens for a missing/nonexistent store name or what the response contains, so it is only minimally additive.
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?
One sentence, front-loaded with the verb and resource, with zero filler. Nothing can be trimmed without losing the identifying-key detail.
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 single-parameter read tool with full schema coverage and annotations covering safety, the description is nearly sufficient; absent an output schema it need not explain return values. Only the lack of any sibling/usage routing keeps it from a 5.
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% and the single store_name parameter is documented in the schema with the 'fileSearchStores/abc123' format example. The description's mention of 'resource name' adds no meaning beyond that, so the baseline 3 applies.
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?
States a specific verb ('Get') and resource ('Gemini File Search store') plus the identifying key ('by its resource name'), so an agent knows exactly which entity is fetched. It does not explicitly contrast itself with the sibling gemini_list_stores, which keeps it short of a 5.
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?
There is no statement of when to use this versus gemini_list_stores (retrieve many) or the other store/detail siblings, and no prerequisites or error conditions are mentioned. Usage is only weakly inferable from the phrase 'a specific store'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the status of a file upload operation. Returns whether the upload is done and any error details.
| Name | Required | Description | Default |
|---|---|---|---|
| operation_name | Yes | Upload operation resource name, e.g. "fileSearchStores/abc123/upload/operations/op789" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint, so safety is covered. The description adds genuine value beyond that by disclosing the response content (done status and error details) for a tool with no output schema.
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 short sentences, front-loaded with the purpose and followed by the return content. No filler, no 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 single-parameter, read-only status check with no output schema, the description covers the essential return shape (done state, error details). It stops short of describing the operation lifecycle (e.g., that the name may expire or how to recover from a failed 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 description coverage is 100%, so the single parameter is fully documented in the schema, including a concrete resource-name example. The description adds no meaning beyond what the schema already provides, so the baseline 3 applies.
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?
States a specific verb and resource: 'Check the status of a file upload operation.' It is somewhat distinguishable from the generic sibling gemini_get_operation, but it never explicitly names or contrasts with that sibling, leaving the differentiation to inference.
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 is only implied: an agent can infer this is polled after gemini_upload_to_store or gemini_import_file_to_store, but the description states no when-to-use condition, no polling guidance, and no exclusions relative to gemini_get_operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import a file from the Gemini Files API into a File Search store. Use this for large files that were uploaded separately via the Files API. Returns an operation to track import progress.
| Name | Required | Description | Default |
|---|---|---|---|
| file_name | Yes | Gemini file resource name, e.g. "files/abc-123" | |
| store_name | Yes | Store resource name, e.g. "fileSearchStores/abc123" | |
| custom_metadata | No | Custom metadata key-value pairs for filtering (max 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as a non-read-only, non-destructive, non-open-world write. The description adds the meaningful behavioral fact that the call returns an operation object for tracking progress, i.e. it is asynchronous, which is not derivable from annotations and matters for an agent's follow-up handling. It does not disclose auth needs or any mutate-vs-reference semantics.
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 zero padding: what it does, when to reach for it, and what it returns, in that order. Nothing restates the name or title and nothing could be dropped without losing information.
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?
With no output schema, the description usefully compensates by stating the return is an operation. The only real gap is not pointing at the sibling operation-polling tool for the async follow-up, which would close the loop for a multi-step import flow.
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% and all three parameters, including the custom_metadata shape and its 20-item cap, are documented in the schema. The description adds no parameter-level detail, so the baseline 3 applies.
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?
States a specific verb and resource chain: import a file from the Gemini Files API into a File Search store. The scenario sentence ('large files that were uploaded separately via the Files API') implicitly separates it from the sibling gemini_upload_to_store, but no sibling is named, so an agent must still infer the boundary.
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?
Gives a clear selection condition: use this when the file was already uploaded separately via the Files API, which contrasts with an upload-from-scratch path. It stops short of naming gemini_upload_to_store as the alternative or stating a when-not condition, so it is clear context without explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List documents in a Gemini File Search store. Returns document names, display names, state, size, and MIME types.
| Name | Required | Description | Default |
|---|---|---|---|
| page_size | No | Number of documents to return per page (default 10, max 20) | |
| page_token | No | Token for next page from previous response | |
| store_name | Yes | Store resource name, e.g. "fileSearchStores/abc123" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds value by enumerating the returned fields (names, display names, state, size, MIME types), but says nothing about pagination behavior or ordering, which matter for a list operation.
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 compact sentences, front-loaded with the purpose and followed by the return shape. No filler and nothing redundant with the schema.
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?
With no output schema, the description usefully enumerates returned fields, and annotations cover the safety profile. Pagination is handled by the schema, but the description could note that results are paged, a common pitfall for list tools.
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%: page_size, page_token, and store_name all carry their own schema descriptions including defaults and limits. The description adds no parameter-level detail, so the baseline 3 applies.
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 gives a specific verb and resource ('List documents in a Gemini File Search store'), which cleanly separates it from gemini_list_stores (lists stores) and gemini_get_document (retrieves one). It stops short of explicitly naming those siblings, so an agent must infer the distinction from the noun alone.
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 is implied by the scope: enumerate documents within a known store. However, there is no explicit guidance on when to prefer this over gemini_get_document for a single document, and no mention of required store existence or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all Gemini File Search stores. Returns store names, display names, and timestamps. Use to see available knowledge bases.
| Name | Required | Description | Default |
|---|---|---|---|
| page_size | No | Number of stores to return per page (default 10, max 20) | |
| page_token | No | Token for next page from previous response |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description usefully adds the return shape (names, display names, timestamps), but says nothing about pagination behavior or empty-result handling beyond what the schema implies.
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 short sentences, action first, return shape second, usage hint third. No filler and nothing buried.
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 read-only list tool with full schema coverage, annotations, and no output schema, the description is nearly sufficient. Only pagination/return-envelope behavior is left implicit.
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%, so both page_size and page_token are fully documented in the schema with defaults and limits. The description adds no parameter meaning beyond that, so the 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?
States a specific verb and resource ('List all Gemini File Search stores') and names the returned fields. It is clearly distinguishable from gemini_get_store or gemini_create_store, but it does not explicitly name or contrast 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Use to see available knowledge bases' implies a browsing/discovery context but gives no when-not guidance, no note on how this differs from gemini_list_documents, and no mention of how pagination interacts with repeated calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query your documents using Gemini RAG. Sends a natural language query grounded in your File Search stores. Returns AI-generated answer with source citations from your documents.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Gemini model to use (default: "gemini-2.5-flash-lite"). Options: gemini-2.5-flash-lite, gemini-2.5-flash, gemini-2.5-pro | |
| query | Yes | Natural language query to search your documents | |
| store_names | Yes | Array of store resource names to search, e.g. ["fileSearchStores/abc123"] | |
| metadata_filter | No | Optional metadata filter expression (Google AIP-160 syntax) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavior beyond that: it returns an AI-generated answer with source citations grounded in File Search stores, which is not inferable from annotations. It omits any mention of latency, cost differences across models, or failure modes for nonexistent stores.
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, purpose front-loaded, with the retrieval mechanism and return format each getting exactly one clause. Nothing is redundant or padded.
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?
No output schema exists, but the description covers the return shape (generated answer plus citations), and the schema fully documents inputs. What is missing is any prerequisite linking to sibling tools for discovering valid store names and a note on behavior when a store is empty or invalid.
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 all four parameters (model, query, store_names, metadata_filter) are already documented with examples and valid values. The description only alludes to store_names via 'grounded in your File Search stores' and adds no syntax or formatting detail 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?
States a specific verb (query) and resource (your documents) plus the grounding mechanism (File Search stores). The sibling list is entirely store/document CRUD management, so this tool's retrieval role is unambiguous without opening any 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 is implied rather than stated: an agent can infer this is for answering questions over indexed documents, but there is no explicit when-to-use/when-not-to-use guidance. It also doesn't tell the agent to call gemini_list_stores first to obtain valid store resource names, which is a required input.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload content directly to a Gemini File Search store. Accepts text content or base64-encoded binary. For large files, use gemini_import_file_to_store instead. Returns an operation to track upload progress.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The content to upload. Plain text by default, or base64-encoded if content_encoding is "base64" | |
| mime_type | Yes | MIME type of the content, e.g. "text/plain", "application/pdf", "text/markdown" | |
| store_name | Yes | Store resource name, e.g. "fileSearchStores/abc123" | |
| display_name | No | Display name for the document (optional) | |
| custom_metadata | No | Custom metadata key-value pairs for filtering (max 20) | |
| content_encoding | No | How the content is encoded: "text" (default) or "base64" for binary files |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds real context beyond them: accepted input forms (text or base64 binary) and that the result is an operation to track progress. It stops short of noting that the target store must already exist or any quota limits.
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, front-loaded with the core action, then the alternative, then the return type. No sentence is wasted and each carries distinct information.
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 write tool with no output schema, the description covers the action, input formats, the large-file alternative, and the asynchronous return shape. It omits the precondition that store_name must reference an existing store, which is a minor but real gap for an upload 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 schema already documents all six parameters including the base64 encoding toggle and metadata cap. The description only echoes the text-vs-base64 distinction, adding little beyond structured data. Baseline 3 applies.
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?
States a specific verb and resource (upload content directly to a Gemini File Search store) and immediately distinguishes itself from the sibling gemini_import_file_to_store. An agent can separate it from other store/document tools 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?
Explicitly routes the agent: 'For large files, use gemini_import_file_to_store instead.' That names the alternative and the condition that selects it, which is exactly what usage guidance should do.
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.
v1.0.2gemini_create_storegemini_delete_documentgemini_delete_storegemini_get_documentgemini_get_operationgemini_get_storegemini_get_upload_operationgemini_import_file_to_storegemini_list_documentsgemini_list_storesgemini_rag_querygemini_upload_to_storeScored across 12 tools
Most tools target a distinct resource+action (store CRUD, document CRUD, query), but two pairs risk confusion: gemini_get_operation vs gemini_get_upload_operation both poll operation status, and gemini_upload_to_store vs gemini_import_file_to_store both ingest content. The descriptions do clarify the distinctions (store vs upload operations; direct content vs Files API), keeping it mostly clean.
Every tool follows the same gemini_<verb>_<noun> convention (gemini_list_stores, gemini_get_store, gemini_delete_document, gemini_rag_query). The pattern is predictable and uniform across all 12 tools.
12 tools is well-scoped for a RAG/file-search server, covering store lifecycle, document lifecycle, ingestion, operation polling, and query. Each tool earns its place without redundancy.
Store lifecycle (create/get/list/delete) and document read/delete plus ingestion and query are well covered. Minor gaps exist: no store/document update or rename operation, and document creation is only via upload/import, but core workflows are complete.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
The CustomGPT.ai MCP server is a fully managed, RAG-powered endpoint that connects large language models with private knowledge bases and external data sources. It provides tools for retrieval-augmented generation queries (send_message), data ingestion (upload_file), and source listing, enabling AI agents to query private documents like PDFs with high accuracy and real-time citations.
The Needle MCP server enables semantic search on documents stored in files like PDFs, DOCX, and XLSX by connecting AI applications to external data sources. It provides capabilities to create and manage document collections, perform natural language searches on stored content, and retrieve relevant information without requiring exact keyword matches.
