search-context
Provides semantic search over documentation using Google's Gemini File Search API, enabling natural language queries with AI-generated answers and source citations from FileSearchStores.
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., "@search-contextsearch how to set up authentication in the factory docs"
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.
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)
ā
ClaudeKey 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
Recommended: npx
npx -y github:ain3sh/search-contextNo 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 startConfiguration
Environment Variables
GEMINI_API_KEY(required): Your Gemini API keyLOG_LEVEL(optional):debug,info, orerror(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_hereUsage
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-docsNote: 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 previewsParameters
store(string, required): Store name from MCP Resources e.g."context","Factory-AI/factory"query(string, required): Natural language queryinclude_chunks(boolean, optional): Include chunk previews (default:false)top_k(number, optional): Chunks to retrieve wheninclude_chunks=trueDefault:3, max:20response_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.mdWith 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 ( | ~500ā1000 | Synthesized answer + source citations |
With chunks ( | ~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
Cost Model (Gemini File Search)
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:
Set
GEMINI_API_KEYas a repository secretCreate a workflow that:
Clones/fetches documentation files
Uses Gemini File Search API to create/update stores
Sets a
displayNamefor each store (this becomes the store name in MCP)
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 startProject 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.mdQuick 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
displayNamematches what you're queryingRestart the MCP server (store list is cached at startup)
API Key Problems
Symptoms: UNAUTHENTICATED, Invalid API key
Check:
GEMINI_API_KEYis set in environment/configKey works at https://aistudio.google.com/apikey
File Search API access is enabled
Quota not exceeded (free tier ~1500 RPD)
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 buildcompletes without errorsMCP config JSON is valid
Client logs (e.g.
~/Library/Logs/Claude/mcp*.log)npxcan access GitHubManual run works:
GEMINI_API_KEY=key npx -y github:ain3sh/search-context
License
MIT License ā see LICENSE.
Available Tools
1 toolask_docs_agentAsk Documentation AgentARead-onlyIdempotent
AI-powered semantic search for complex documentation questions. Best for conceptual queries, multi-part research, and understanding how systems work.
How to Use:
Find available references: Check MCP Resources list - each resource is a searchable documentation reference
Ask your question: Use natural language, be specific about what you want to understand
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.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Natural language search query | |
| store | Yes | Documentation reference name (directory path). Examples: 'context', 'Factory-AI/factory' | |
| top_k | No | Number of relevant document chunks to retrieve (1-20). Only relevant when include_chunks=true. | |
| include_chunks | No | Include retrieved document chunks in response (default: false). When false, only returns synthesized answer + sources. When true, includes chunk previews for verification. | |
| metadata_filter | No | Optional metadata filter using List Filter syntax (google.aip.dev/160). Example: 'author="Robert Graves" AND year=1934' | |
| response_format | No | Output format: 'markdown' for human-readable or 'json' for structured data | markdown |
TDQS
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.
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.
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.
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.
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.
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 tool update
v1.0.0- First observed
ask_docs_agent
TDQS
Scored across 1 tool
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.
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.
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.
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
Related MCP Connectors
Search and reason over your Obsidian-style Markdown vault, right from ChatGPT.
Search your knowledge bases from any AI assistant using hybrid RAG.
Search and query nTop's knowledge base and engineering guides from AI applications.
Securely search and manage workspace context files for AI agents and teams.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceEnables intelligent ingestion and querying of PDF, Markdown, and text files using hybrid search that combines keyword matching and semantic embeddings with citations.2-
- AlicenseNot gradedqualityDmaintenanceEnables web search using Google Gemini with search grounding and question-answering on local documents, with support for chunked document reading.6 npm1MIT
- AlicenseAqualityDmaintenanceEnables document Q&A with grounded citations using the official Gemini File Search API. Upload documents, create stores, and ask questions that return exact passage citations.715 npm2MIT
- FlicenseNot gradedqualityCmaintenanceEnables searching a knowledge base and asking grounded questions with hybrid retrieval, reranking, and cited answers.-