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 "Install 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 Related Servers Score Discussions

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.3/5.0

Behavior2/5

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

Without annotations, the description has high burden. It discloses the core actions (scan, extract, embed, store) but omits behavioral details like whether indexing is incremental or full, if overwrites existing data, handling of unchanged files, required permissions, or side effects on system resources.

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

Conciseness5/5

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

Two well-structured sentences for the main purpose, plus a terse Args list. Every sentence is informative without redundancy. Excellent front-loading of the tool's primary action.

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 complexity (file scanning, embedding generation) and presence of an output schema, the description is partially complete. It covers input parameters and common file types but omits recursion behavior, handling of unsupported files, return value, and potential performance impact. The output schema may fill some gaps, but the description could still be more thorough.

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

Parameters3/5

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

Schema coverage is 0%, so the description adds needed meaning by clarifying directory_path as absolute path and ignore as optional glob patterns with examples. However, it does not specify pattern syntax or that ignore works on basenames versus full paths, leaving some ambiguity.

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?

Clearly states the tool scans a local directory, extracts text from specific file types and raw bytes from media files, generates embeddings using Gemini 2, and stores them for searching. This precise verb+resource combination distinguishes it from siblings like list_indexed_directories and 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 explicit guidance on when to use this tool versus alternatives like sync_indexed_directories or remove_directory_from_index. It does not mention prerequisites, when to re-index, or when indexing is not appropriate.

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_indexB

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

B3.2/5.0

Behavior2/5

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

No annotations are present, so the description must carry the full burden. It only mentions 'removes' without clarifying reversibility, scope (index vs files), error conditions, or side effects, leaving significant behavioral ambiguity.

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

Conciseness5/5

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

The description is a single sentence that communicates the core purpose efficiently, with no extraneous information. It is front-loaded and well-structured.

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 simplicity (one parameter, no annotations, but with an output schema not detailed), the description is minimally adequate but lacks details on return values, success/failure indications, or any side effects, leaving gaps for a complete understanding.

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%, and the description adds no meaning beyond the parameter name 'directory_path'. It does not specify format, constraints, or examples, so the agent cannot infer valid input beyond the minimal type information.

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

Purpose5/5

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

The description clearly states the action ('Removes') and the resource ('all documents and images belonging to a specific directory path from the index'), effectively distinguishing it from sibling tools 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?

The description provides no guidance on when to use this tool vs alternatives, no prerequisites, and no exclusions. Given sibling tools like index_directory and sync_indexed_directories, the agent lacks information to choose correctly.

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.2/5.0

Behavior3/5

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

Without annotations, the description bears full burden. It explains the process (finding parent directories and re-indexing) but omits details like handling deleted files, potential performance impact, or whether it is safe to run concurrently.

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

Conciseness5/5

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

Two sentences with no wasted words. The structure is clear and front-loaded with the primary action.

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?

Given no parameters and an existing output schema, the description provides sufficient operational context. It could mention that the action is system-wide and may take time, but is otherwise adequate.

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?

No parameters exist; schema coverage is trivially 100%. The description does not need to add parameter info, achieving the baseline for zero-parameter tools.

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 indexed files, distinguishing it from sibling tools like index_directory which handles initial indexing.

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

Usage Guidelines4/5

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

The description implies usage for updating existing indexes, but does not explicitly state when not to use it or provide alternatives. However, the context of sibling tools aids in understanding.

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. Dates show when Glama detected each change.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.7/5.0

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

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

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
19212
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
23
12
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

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AlaeddineMessadi/gemini-embedding-2-mcp-server'

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