Skip to main content
Glama
ain3sh

search-context

by ain3sh

Search Context MCP Server

A generic MCP server that provides semantic search over documentation using Gemini File Search.

What it does: Queries Gemini FileSearchStores in the cloud and returns AI-generated answers with source citations.

What it doesn't do: Index files, manage git repos, or run workflows. Indexing happens separately (e.g., via GitHub Actions in your docs repo, or any custom pipeline).

Features

  • šŸ” Semantic search using Gemini File Search API

  • šŸ¤ Dynamic store discovery via Gemini API (no local configuration needed)

  • 🧠 Natural language queries with source citations

  • ⚔ Token-efficient responses (~500–1000 tokens by default)

  • šŸ“Š Dual formats: Markdown (human-readable) and JSON (programmatic)

  • 🌐 Generic: Works with any Gemini FileSearchStores you've created


Related MCP server: Gemini Search MCP

Architecture

Your indexing pipeline → Gemini FileSearchStores (cloud)
                              ↓
                         search-context MCP server (local)
                              ↓
                            Claude

Key points:

  • MCP server only queries cloud-based FileSearchStores

  • Does not interact with git repos or local files

  • Stores are created and updated by your indexing workflow

  • Server discovers stores dynamically via client.file_search_stores.list()


Quick Start

npx -y github:ain3sh/search-context

No cloning required. Always uses the latest version from GitHub.

From Source

git clone https://github.com/ain3sh/search-context.git
cd search-context
npm install
npm run build
npm start

Configuration

Environment Variables

  • GEMINI_API_KEY (required): Your Gemini API key

  • LOG_LEVEL (optional): debug, info, or error (default: info)

Get an API key: https://aistudio.google.com/apikey

Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "search-context": {
      "command": "npx",
      "args": ["-y", "github:ain3sh/search-context"],
      "env": {
        "GEMINI_API_KEY": "your_api_key_here"
      }
    }
  }
}

Claude Code (Project-Level)

Create .mcp.json in your project root:

{
  "mcpServers": {
    "search-context": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "github:ain3sh/search-context"],
      "env": {
        "GEMINI_API_KEY": "${GEMINI_API_KEY}"
      }
    }
  }
}

Then set:

export GEMINI_API_KEY=your_api_key_here

Usage

Discovering Stores

Stores are exposed as MCP Resources. Clients can discover them via resources/list.

The server queries Gemini's API on startup to find all available FileSearchStores and exposes them as URIs:

store://context
store://Factory-AI/factory
store://other-docs

Note: Store names come from the displayName field you set when creating the FileSearchStore.

Searching Documentation

Use the search_context tool with natural language queries:

// Minimal query (common case)
search_context({
  store: "context",
  query: "How does File Search chunking work?"
})
// → ~500–1000 tokens, answer + citations

// With evidence chunks (for verification)
search_context({
  store: "context",
  query: "authentication flow setup",
  include_chunks: true
})
// → ~2000–3000 tokens, answer + citations + chunk previews

Parameters

  • store (string, required): Store name from MCP Resources e.g. "context", "Factory-AI/factory"

  • query (string, required): Natural language query

  • include_chunks (boolean, optional): Include chunk previews (default: false)

  • top_k (number, optional): Chunks to retrieve when include_chunks=true Default: 3, max: 20

  • response_format (string, optional): "markdown" or "json" (default: "markdown")

  • metadata_filter (string, optional): Advanced filter using List Filter syntax

Response Format

Default (response_format="markdown", include_chunks=false):

# Search Results: context

**Query**: How does chunking work?

**Response**:
[Synthesized answer from semantic search]

---

**Sources** (2 files):
  - ai.google.dev_gemini-api_docs_file-search.md
  - CONTEXT_SEARCH_MCP_SPEC.md

With chunks (include_chunks=true):

[... same as above, plus ...]

---

## Retrieved Context Chunks

### [1] ai.google.dev_gemini-api_docs_file-search.md

Files are automatically chunked when imported into a file search store...
[truncated to 500 chars per chunk]

---

JSON responses include structured query, response, sources, and optional chunks[].


Performance & Cost

Token Efficiency

Responses are optimized to avoid context spam:

Mode

Tokens (approx.)

Contents

Default (include_chunks=false)

~500–1000

Synthesized answer + source citations

With chunks (include_chunks=true)

~2000–3000

Answer + sources + 500-char chunk previews

Safeguards:

  • Chunk previews truncated to 500 characters

  • Full responses capped at 25,000 characters

  • Store metadata cached for 5 minutes

For the MCP server (querying):

  • Queries: Free; retrieved chunks are charged as normal context tokens to your Gemini API usage

For indexing (done separately by your pipeline):

  • Indexing: ~$0.15 per 1M tokens (one-time per file; re-run only when file changes)

  • Storage: Free

Example monthly estimate (if using a daily indexing workflow):

  • 100 files (~150k tokens): ~$0.0225 per sync

  • Daily syncs, small changes: ~$0.25–$1/month

  • Heavy churn / active development: ~$3–$6/month


Setting Up Indexing (Separate from MCP Server)

The MCP server only queries existing Gemini FileSearchStores. You need a separate process to create and update these stores.

Option 1: GitHub Actions Workflow

If you have a docs repository, you can automate indexing with GitHub Actions.

Example: See ain3sh/docs for a complete implementation:

  • mirrors.json: Configuration for which repos/directories to index

  • .github/scripts/sync.py: Script that creates/updates FileSearchStores

  • .github/workflows/sync.yml: Workflow that runs daily and on changes

Key steps:

  1. Set GEMINI_API_KEY as a repository secret

  2. Create a workflow that:

    • Clones/fetches documentation files

    • Uses Gemini File Search API to create/update stores

    • Sets a displayName for each store (this becomes the store name in MCP)

  3. Run daily or on file changes

Option 2: Custom Pipeline

You can index from any environment:

from google import genai

client = genai.Client(api_key=os.getenv("GEMINI_API_KEY"))

# Create a store
store = client.file_search_stores.create(
    display_name="my-docs"  # This becomes store://my-docs in MCP
)

# Upload files
for file_path in doc_files:
    client.file_search_stores.upload_file(
        store_id=store.id,
        path=file_path
    )

Store Naming

The displayName you set when creating a FileSearchStore becomes its MCP resource URI:

# In your indexing script:
store = client.file_search_stores.create(display_name="context")

# In MCP:
search_context({ store: "context", query: "..." })

Development

Local Development

# Install dependencies
npm install

# Build
npm run build

# Development mode (auto-reload)
npm run dev

# Run with API key
GEMINI_API_KEY=your_key npm start

Project Structure

search-context/
ā”œā”€ā”€ src/
│   └── index.ts            # Main MCP server implementation
ā”œā”€ā”€ dist/
│   └── index.js            # Compiled output (committed for npx)
ā”œā”€ā”€ package.json            # Includes bin field for CLI
ā”œā”€ā”€ tsconfig.json
└── README.md

Quick Local Test

npm run build
timeout 5s GEMINI_API_KEY=your_key npx .

MCP servers are long-lived; real testing is best via an MCP client (Claude Desktop, Claude Code, etc.).


Troubleshooting

Store Not Found

Error: Error: Store 'xyz' not found

Check:

  • Store exists in Gemini (visit Google AI Studio)

  • Store has files uploaded

  • Store's displayName matches what you're querying

  • Restart the MCP server (store list is cached at startup)

API Key Problems

Symptoms: UNAUTHENTICATED, Invalid API key

Check:

No Results

Symptoms: "No results found"

Try:

  • Broader or more precise query wording

  • Confirm files exist in the store (check Google AI Studio)

  • Confirm indexing completed successfully

  • Use terms closer to the docs' own wording

  • Ensure files use supported formats (Markdown, text, PDF, etc.)

Rate Limits

Error: 429, RESOURCE_EXHAUSTED

  • Free tier: ~15 RPM

  • Wait 60 seconds before retrying

  • Reduce query rate

  • If needed, upgrade to a paid tier

Server Not Loading in Client

Symptoms: MCP client doesn't show search-context

Check:

  • npm run build completes without errors

  • MCP config JSON is valid

  • Client logs (e.g. ~/Library/Logs/Claude/mcp*.log)

  • npx can access GitHub

  • Manual run works:

    GEMINI_API_KEY=key npx -y github:ain3sh/search-context

License

MIT License – see LICENSE.

Available Tools

1 tool
ask_docs_agentAsk Documentation AgentA
Read-onlyIdempotent

AI-powered semantic search for complex documentation questions. Best for conceptual queries, multi-part research, and understanding how systems work.

How to Use:

  1. Find available references: Check MCP Resources list - each resource is a searchable documentation reference

  2. Ask your question: Use natural language, be specific about what you want to understand

  3. Default response includes synthesized answer + source citations (token-efficient)

Required: • store: Reference name from MCP Resources (e.g., "context", "Factory-AI/factory") • query: Your question in natural language

Optional (use when needed): • include_chunks: true - Show document excerpts for verification (increases tokens ~3x) • top_k: 1-20 - Number of excerpts when include_chunks=true (default: 3) • response_format: "json" - Structured output instead of markdown • metadata_filter: Advanced filtering using List Filter syntax

Effective Queries: āœ… "How does authentication work and why is it designed this way?" āœ… "What are the key differences between async and sync processing?" āœ… "Explain the rate limiting strategy and its tradeoffs" āŒ "authentication" (too vague) āŒ Single keywords without context

Finding References: All available documentation references are registered as MCP Resources. Use the Resources list to see what's searchable. Each top-level directory from ain3sh/docs is its own reference.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesNatural language search query
storeYesDocumentation reference name (directory path). Examples: 'context', 'Factory-AI/factory'
top_kNoNumber of relevant document chunks to retrieve (1-20). Only relevant when include_chunks=true.
include_chunksNoInclude retrieved document chunks in response (default: false). When false, only returns synthesized answer + sources. When true, includes chunk previews for verification.
metadata_filterNoOptional metadata filter using List Filter syntax (google.aip.dev/160). Example: 'author="Robert Graves" AND year=1934'
response_formatNoOutput format: 'markdown' for human-readable or 'json' for structured datamarkdown

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower, but the description still adds substantial context: the default response is a synthesized answer plus citations, and include_chunks increases token usage ~3x. That cost/behavior disclosure is genuinely useful and goes beyond what the annotations provide.

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?

Well-structured and front-loaded, with the purpose stated first and clear bolded sections for workflow, required/optional params, and query examples. It is somewhat long, and the Required/Optional bullet list partially duplicates the schema, costing it a point on strict conciseness.

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

Completeness5/5

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

For a 6-parameter tool with no output schema, the description compensates by describing the return shape (synthesized answer + citations, or structured JSON) and the token tradeoffs of retrieval options. An agent has everything needed to call it correctly and anticipate the response.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3 and the schema already documents all six parameters, including the top_k/include_chunks dependency. The description adds some value by giving concrete store examples and framing query as natural language, but much of the Required/Optional section restates what the schema already says.

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?

States a specific verb+resource ("AI-powered semantic search for complex documentation questions") and scopes it precisely to "conceptual queries, multi-part research, and understanding how systems work." There are no siblings to differentiate from, but the description also distinguishes itself from naive keyword search by explicitly rejecting single-keyword queries.

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

Usage Guidelines5/5

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

Provides explicit when-to-use guidance (conceptual, multi-part research), when-not-to-use (āŒ "authentication" too vague, single keywords), a step-by-step workflow, and a concrete method for discovering valid store values via the MCP Resources list. Nothing about selection or prerequisites is left to inference.

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.

  1. 1 tool updatev1.0.0
    • First observedask_docs_agent

TDQS

A4.5/5.0

Scored across 1 tool

Disambiguation5/5

With only one tool, there is no possibility of misselection or overlap with sibling tools. Its purpose (semantic documentation Q&A) is stated clearly and unambiguously in the description.

Naming Consistency4/5

The single name ask_docs_agent is readable snake_case and follows a verb-object-ish convention. There is no second tool to establish or violate a pattern, so consistency is trivially satisfied but unverifiable.

Tool Count3/5

One tool is borderline thin even for a narrowly scoped search server; reference discovery is offloaded to MCP Resources rather than tools. It is defensible for a single-purpose server, but a search plus retrieval pair would feel better scoped.

Completeness3/5

Search is covered, but there is no tool to list available stores or fetch a full document by identifier — agents must fall back on the MCP Resources list and rely on snippets. That is a notable gap for a documentation research surface.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers