Which integrations are available for this server?

Allows connection to Windsurf (Cascade) for searching and retrieving local multimodal documents. Uses Google's Gemini Embedding 2 model for multimodal embedding and search.

How do I use Gemini Embedding 2 MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Gemini Embedding 2 MCP Server find PDF pages about design tokens" 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.

Gemini Embedding 2 MCP Server

by AlaeddineMessadi

Overview Schema Source Related Servers Discussions Admin

Python

Local

License: MIT Python MCP

Connect your local documents, code, PDFs, images, audio, and video directly to Claude, Cursor, or VS Code using Google's gemini-embedding-2-preview model and a strictly local ChromaDB vector database.

Unlike text-only local RAG tools, this server keeps one local memory layer across text, visual PDF pages, images, audio, and video, then returns exact file paths and page or chunk context back to your agent.

Why This Is Different

One embedding space across modalities: Search code, PDFs, images, audio, and video from the same memory layer.
Local-first persistence: Your index stays in ~/.gemini_mcp_db, not in a hosted vector database.
Agent-friendly retrieval: Search results include exact paths, types, modalities, and page-aware context.
Zero-config by default: The server uses built-in guardrails and sensible indexing defaults so most users do not need a config file.

Related MCP server: Mnemos

What You Can Ask

Find the PDF page that explains our design tokens.
Search my image library for screenshots of dashboards with dark sidebars.
Find the audio or video clip where we talked about pricing changes.
Search only my work docs folder for onboarding notes about incident response.
Give me the surrounding context for result 2 so I can cite the original file correctly.

✨ Key Features

Feature	Description
🧠 Unified Multimodal Search	Stores text, visual PDF pages, images, audio, and video in one local semantic memory so a single query can retrieve across modalities.
📄 Visual PDF Retrieval	Renders PDFs page-by-page as images for Gemini Embedding 2 while retaining extracted text for agent-readable citations and context.
🎯 Precision Retrieval Controls	Supports compact filters for scope, path prefix, type, extension, and modality so agents can search precisely without heavy configuration.
👀 Preview Before Indexing	`preview_directory()` shows what will be indexed, grouped by modality and skip reason, before the scan runs.
🧾 Context-Aware Results	`get_result_context()` returns neighboring chunks or pages so agents can inspect exact source material after search.
🛡️ Local Privacy + Guardrails	Uses a local ChromaDB store, skips junk folders by default, blocks dangerous root scans, and handles deduplication and ghost-file cleanup automatically.

🚀 Installation & Setup

We support two ways to run this server: Zero-Install (Recommended) or Local Developer Clone. Make sure you have uv installed on your machine (pip install uv).

Method 1: Zero-Install (Recommended)

You can point your AI assistant to run the server directly from GitHub without ever cloning the repository locally. uvx acts like npx for Python, downloading and caching the server in a secure ephemeral environment automatically.

PyPI is configured as the long-term stable distribution channel for tagged releases. Until the first PyPI publish completes, use the pinned Git release-tag install below.

For a stable install, pin to a release tag:

uvx --from git+https://github.com/AlaeddineMessadi/gemini-embedding-2-mcp-server.git@<release-tag> gemini-embedding-2-mcp

Example:

uvx --from git+https://github.com/AlaeddineMessadi/gemini-embedding-2-mcp-server.git@v1.2.1 gemini-embedding-2-mcp

For an edge install, omit the tag and track the latest main branch state.

Once PyPI publishing is live, the stable install command becomes:

uvx gemini-embedding-2-mcp-server

🔑 Getting your Gemini API Key

To power the embedding model, you need a free API key from Google.

Go to Google AI Studio.
Click Create API key.
Copy the key and use it in your client configurations below as GEMINI_API_KEY.

🔌 Client Connection Guides

🤖 Claude Code (CLI)

You can attach this server to the Claude Code CLI natively. Run the following command in your terminal:

claude mcp add gemini-embedding-2-mcp \
  --env GEMINI_API_KEY="your-api-key-here" \
  -- uvx --from git+https://github.com/AlaeddineMessadi/gemini-embedding-2-mcp-server.git@v1.2.1 gemini-embedding-2-mcp

🦋 Claude Desktop

Open your Claude Desktop config file (usually ~/Library/Application Support/Claude/claude_desktop_config.json on macOS) and add:

{
  "mcpServers": {
    "gemini-embedding-2-mcp": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/AlaeddineMessadi/gemini-embedding-2-mcp-server.git@v1.2.1",
        "gemini-embedding-2-mcp"
      ],
      "env": {
        "GEMINI_API_KEY": "your-api-key-here"
      }
    }
  }
}

💻 Cursor IDE

Go to Settings > Features > MCP
Click + Add new MCP server
Choose command as the type.
Name: gemini-embedding
Command: GEMINI_API_KEY="your-api-key" uvx --from git+https://github.com/AlaeddineMessadi/gemini-embedding-2-mcp-server.git@v1.2.1 gemini-embedding-2-mcp

🏄‍♂️ Windsurf (Cascade)

Open your ~/.codeium/windsurf/mcp_config.json file and add:

{
  "mcpServers": {
    "gemini-embedding-2-mcp": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/AlaeddineMessadi/gemini-embedding-2-mcp-server.git@v1.2.1",
        "gemini-embedding-2-mcp"
      ],
      "env": {
        "GEMINI_API_KEY": "your-api-key-here"
      }
    }
  }
}

⚡ Zed Editor

Open your ~/.config/zed/settings.json and append the MCP server block:

{
  "experimental.mcp": {
    "gemini-embedding-2-mcp": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/AlaeddineMessadi/gemini-embedding-2-mcp-server.git@v1.2.1",
        "gemini-embedding-2-mcp"
      ],
      "env": {
        "GEMINI_API_KEY": "your-api-key-here"
      }
    }
  }
}

💻 VS Code (with Cline / RooCode)

Open ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json and append:

{
  "mcpServers": {
    "gemini-embedding": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/AlaeddineMessadi/gemini-embedding-2-mcp-server.git@v1.2.1",
        "gemini-embedding-2-mcp"
      ],
      "env": {
        "GEMINI_API_KEY": "your-api-key-here"
      }
    }
  }
}

Method 2: Local Developer Clone

If you want to modify the source code:

# 1. Clone the repository
git clone https://github.com/AlaeddineMessadi/gemini-embedding-2-mcp-server.git
cd gemini-embedding-2-mcp-server

# 2. Install dependencies
uv sync

(If you use this method, you can add it directly to Claude Code CLI locally by running:)

claude mcp add gemini-embedding-local --env GEMINI_API_KEY="your-api-key" -- uv --directory "$(pwd)" run gemini-embedding-2-mcp

Method 3: Docker

If you need a containerized MCP server for registry validation or deployment, build and run the included image:

docker build -t gemini-embedding-2-mcp-server .
docker run --rm -i \
  -e GEMINI_API_KEY="your-api-key-here" \
  -v "$HOME/.gemini_mcp_db:/root/.gemini_mcp_db" \
  gemini-embedding-2-mcp-server

The container communicates over standard I/O like any other local MCP server and persists ChromaDB data in the mounted volume.

🛠️ Exposed MCP Capabilities

Once connected, your AI assistant instantly gains the following tools:

⚙️ Tools

index_directory(path: str, ignore: list = None): Scan and formally embed a completely new local folder into the DB. Safely supports wildcard ignore patterns.
preview_directory(path: str, ignore: list = None): Dry-run a scan and see what would be indexed, grouped by modality and skip reason.
search_my_documents(query: str, limit: int, scope: str = None, types: list[str] = None, path_prefix: str = None, extensions: list[str] = None, modalities: list[str] = None): Run semantic search with compact retrieval filters.
get_result_context(source: str, locator: str = None, window: int = 1): Fetch nearby chunk or page context for a previously indexed result.
list_indexed_directories(): See which directory roots the AI already knows about.
sync_indexed_directories(): Automatically forces the DB to find new, updated, or recently deleted (ghost) files and cleans up vectors.
remove_directory_from_index(path: str): Clears a specific trajectory of vectors.

🔎 Precision Filters

The main search tool stays simple by default, but supports a few high-value filters when you need exactness:

scope: Limit matches to a broad directory scope such as /Users/me/work
path_prefix: Limit matches to a more exact path prefix
types: Restrict by stored item type such as text or pdf_visual_page
extensions: Restrict by file extension such as .pdf or .md
modalities: Restrict by modality such as text, pdf, image, audio, or video

📊 Resources

gemini://database-stats: Real-time observability! Exposes the exact scale of the vector segments inside ChromaDB directly to the assistant's context.

📚 Technical Documentation

📜 License

MIT © Alaeddine Messadi

Available Tools

7 tools

get_result_contextC

Returns nearby chunks or pages for a previously indexed result.

ParametersJSON Schema

Name	Required	Description	Default
`source`	Yes
`locator`	No
`window`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

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. It states the tool 'returns' data, implying read-only, but does not disclose any behavioral traits such as performance, error handling, or what happens if the result is not found.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, concise but missing critical details. It is not verbose, but the conciseness comes at the cost of completeness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the moderate complexity (3 parameters, 1 required) and presence of an output schema, the description is insufficient. It fails to explain how to use the parameters or when this tool is appropriate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explain any of the three parameters (source, locator, window). The agent gets no additional meaning beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns nearby chunks or pages for a previously indexed result, using a specific verb and resource. It distinguishes from sibling tools like index_directory or search_my_documents.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like search_my_documents or preview_directory. There is no indication of prerequisites or context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

index_directoryB

Scans a local directory, extracts text from files (PDF, DOCX, TXT, MD) AND raw video/audio/image bytes, generates semantic embeddings using Gemini 2 and stores them for searching.

Args: directory_path: Absolute path to the directory. ignore: Optional list of glob patterns to ignore (e.g., [".log", "drafts", "temp"]).

ParametersJSON Schema

Name	Required	Description	Default
`directory_path`	Yes
`ignore`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, so the description must fully disclose behavioral traits. It mentions that it generates embeddings and stores them, but fails to disclose side effects such as overwriting behavior, performance implications for large directories, or whether it modifies files. Important safety and idempotency details are missing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (three lines) and front-loaded with the main action. It includes a structured 'Args' section. No unnecessary words, but could be slightly more compact.

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 tool's medium complexity and the presence of an output schema, the description covers the basic functionality well but omits constraints like directory existence, permission requirements, and handling of nested directories. It is adequate but not fully comprehensive.

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 description adds significant meaning beyond the schema by specifying that directory_path must be an absolute path and providing examples for the ignore parameter (e.g., '*.log', 'drafts'). This compensates for the schema's lack of property descriptions (0% 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 the tool scans a local directory, extracts text from multiple file types (PDF, DOCX, TXT, MD, and raw media bytes), generates semantic embeddings using Gemini 2, and stores them for searching. It uses specific verbs and resources, and the function is distinct from siblings like listing or removing indexes.

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 explicit guidance is provided about when to use this tool versus alternatives. It does not mention prerequisites (e.g., directory existence, permissions) or edge cases like re-indexing. The description only explains what it does, not when it should or should not be used.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_indexed_directoriesA

Lists indexed parent directories known to the database.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided. The description indicates a read-only operation but does not explicitly state safety, side effects, or permissions. For a simple listing, it is adequate but could be more explicit.

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 clear sentence with no extraneous information. It is front-loaded and efficiently communicates the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with no parameters and an output schema present. The description covers the basic function. Some additional context about what 'indexed parent directories' entails could improve completeness, but it is sufficient for a list operation.

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 tool has zero parameters, so the description does not need to add parameter details. Baseline 4 is appropriate as there is no omission.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists indexed parent directories known to the database. The verb 'lists' and resource 'indexed parent directories' are specific, and the tool is distinct from siblings like index_directory or remove_directory_from_index.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention context, prerequisites, or conditions that would help an agent decide to invoke it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

preview_directoryB

Summarizes what would be indexed before the server performs a full scan.

ParametersJSON Schema

Name	Required	Description	Default
`directory_path`	Yes
`ignore`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description must fully disclose behavioral traits. It suggests a read-only preview but does not confirm that the operation is non-destructive, require permissions, or handle large directories. Minimal behavioral context is given.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise (one sentence), which is efficient, but it omits important details that could be included without much bloat. Still, it is front-loaded and free of redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema (unknown content) and no parameter descriptions, the description is too sparse. It does not explain what 'summarizes' entails (e.g., file count, sizes), how `ignore` works, or edge cases. For a preview tool, more context is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% for both parameters (`directory_path` and `ignore`). The description does not add any meaning or constraints beyond the schema, leaving the agent uninformed about parameter format, default behavior, or usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: previewing what would be indexed before a full scan. It uses a specific verb ('summarizes') and resource ('what would be indexed'), and effectively distinguishes it from siblings like `index_directory` which performs the actual scan.

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 before a full scan, but it does not provide explicit guidance on when to use this tool versus alternatives like `index_directory` or `search_my_documents`. It lacks 'when not to use' or prerequisite information.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

remove_directory_from_indexC

Removes all documents and images belonging to a specific directory path from the index.

ParametersJSON Schema

Name	Required	Description	Default
`directory_path`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description must carry full burden. States it removes entries but does not disclose if the operation is reversible, impacts other data, or requires permissions. Lacks critical behavioral details for a destructive action.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence, very concise, but lacks depth. While efficient, it fails to include necessary context that would justify its brevity. Not under-specified but could add more value in the same space.

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?

Output schema exists, so return values are covered, but the description omits behavior like confirmation, status, or side effects. For a destructive tool, this is insufficient. Lacks completeness given the simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and description does not elaborate on the single parameter 'directory_path' beyond its name. No format, examples, or constraints are provided, leaving the agent guessing about valid inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool removes documents and images from the index for a specific directory, which is a specific verb+resource. It distinguishes from siblings like index_directory (adds) and list_indexed_directories (lists).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives, no prerequisites or exclusions. The description only implies usage without clarifying context or providing when-not scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_my_documentsC

Performs a semantic search over your previously indexed local documents AND images using the Gemini 2 Embedding model.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes
`limit`	No
`scope`	No
`types`	No
`path_prefix`	No
`extensions`	No
`modalities`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

C2.9/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description bears full burden. It mentions semantic search and the model but fails to disclose read-only nature, rate limits, authentication needs, or behavior on no results. Minimal behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that gets to the point quickly. It is front-loaded with the key action, though it sacrifices completeness for brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 7 parameters with no schema descriptions and no annotations, the description is too brief. It does not cover filtering options or return type, leaving significant gaps despite the presence of an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, yet the description adds no parameter explanations. It only mentions 'documents AND images' but does not detail query, limit, scope, types, path_prefix, extensions, or modalities, leaving the agent to infer from names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool performs semantic search over previously indexed documents and images using Gemini 2 Embedding. It uses a specific verb and resource, distinguishing it from siblings like index_directory or list_indexed_directories.

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 explicit guidance on when to use this tool versus alternatives. The description implies it's for search but doesn't mention when to choose it over siblings like get_result_context or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

sync_indexed_directoriesA

Auto-updates existing folders. It finds all unique parent directories of currently indexed files and re-indexes them to capture new or modified files.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden. It discloses the core behavior: finds unique parent directories and re-indexes them. However, it lacks details on safety (e.g., is it idempotent?), performance, or side effects such as deleting old entries.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the core action 'Auto-updates existing folders.' Every clause adds meaning with no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description is mostly complete for a simple sync action with no parameters. However, it could mention that it is typically run after changes to indexed directories, and it does not describe the return value (though an output schema exists).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, and schema description coverage is 100%. The description does not add parameter info (none needed), but baseline for 0 params is 4. No extra semantic value required.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool auto-updates existing folders by re-indexing parent directories of currently indexed files to capture new or modified files. It distinguishes from sibling tools like index_directory (adds a directory) and list_indexed_directories (lists), showing specific verb+resource.

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 when to use (to sync after changes to indexed directories), but provides no explicit guidance on when not to use or alternatives. It does not compare to siblings like index_directory or remove_directory_from_index.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesv1.2.1May 31, 2026
- First observedget_result_context
- First observedindex_directory
- First observedlist_indexed_directories
- First observedpreview_directory
- First observedremove_directory_from_index
- First observedsearch_my_documents
- First observedsync_indexed_directories

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-05-31 22:34 across 7 tools

Disambiguation5/5

Each tool targets a distinct operation: indexing, previewing, listing, searching, context retrieval, removal, and syncing. No functional overlap exists.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case, e.g., index_directory, list_indexed_directories, search_my_documents. The pattern is uniform and predictable.

Tool Count5/5

With 7 tools, the server covers the essential workflows for local embedding and retrieval without excess or deficiency. The count fits well with the domain scope.

Completeness5/5

Provides a full lifecycle: create (index_directory), read (search, get_result_context, list), update (sync_indexed_directories), delete (remove_directory_from_index), plus a dry-run preview. No obvious gaps.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Living MemoryOAuth
to.viibe
An MCP memory server. One memory your agents share — across models, devices and apps.
Knowledge & Memory Autonomous Agents AI & Machine Learning
22
XMemo AOAuth
io.github.yonro
Shared, governed long-term memory for AI agents across tools and sessions via MCP and REST.
Autonomous Agents Knowledge & Memory
31212
WorkingMemory A
ai.workingmemory
Persistent personal memory for AI assistants — save, search, and recall across every MCP client.
Knowledge & Memory Search
42
nexsusOAuth
io.github.dbnexsus
Private persistent memory for Claude, ChatGPT & Gemini via MCP - semantic search, zero-code setup.
Knowledge & Memory RAG Systems
2

Related MCP Servers

Memento
Knowledge & Memory Databases Vector Databases
iAchilles
A
license
A
quality
C
maintenance
A local, fully-offline MCP memory server that enables persistent storage and retrieval of information using SQLite with both keyword and semantic vector search capabilities.
Updated 3 months ago (2026-06-12 22:05 UTC)
10
19 npm
13
MIT
Mnemos
Knowledge & Memory RAG Systems Vector Databases
Tanush1912
A
license
Not graded
quality
D
maintenance
A self-hosted, multi-context memory server that enables AI agents to search and retrieve information from local documents and crawled websites via MCP tools. It runs fully offline using Postgres and Ollama to provide secure, private knowledge management and retrieval-augmented generation.
Updated 8 months ago (2026-01-15 04:32 UTC)
2
MIT
HKC Memory Server
Knowledge & Memory RAG Systems Vector Databases
ag1357
F
license
Not graded
quality
D
maintenance
An MCP server for managing persistent AI memory using hybrid search (keyword + semantic vector) with SQLite storage and offline-first local embeddings.
Updated a year ago (2025-10-06 10:58 UTC)
-
ctrl-memory
Knowledge & Memory Search RAG Systems
ctrlProgrammer
A
license
Not graded
quality
B
maintenance
A lightweight, local-first MCP memory server for LLM agents that enables storing, searching, and retrieving agent memories with zero external dependencies.
Updated 2 months ago (2026-07-16 00:48 UTC)
1
MIT