Semantic Search MCP Server
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., "@Semantic Search MCP Serverfind the code that handles user authentication and session management"
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.
Semantic Search MCP Server
A local Model Context Protocol (MCP) server that enables AI agents to perform semantic search over codebases using natural language queries. The server converts queries into efficient text search patterns (grep/ripgrep) and verifies relevance before returning results.
Quick Setup
Installation
pip install -e .Environment Variables
Set the following environment variables:
REPO_PATH- Path to the repository to search (defaults to current directory)SEARCHER_TYPE- Searcher implementation to use (default:sgr_gemini_flash_lite)
API Keys (choose one based on your searcher type):
For Claude-based searchers:
CLAUDE_API_KEYorANTHROPIC_API_KEYFor Gemini-based searchers:
GOOGLE_API_KEY,GEMINI_API_KEY,AI_STUDIO, orVERTEX_AI_API_KEYFor OpenAI-based searchers:
OPENAI_API_KEY
Available Searchers
SGR (Schema-Guided Reasoning) searchers - Production-ready implementations:
sgr/sgr_gemini_flash_lite- Default, recommended (Gemini Flash Lite)sgr_gemini_flash- SGR with Gemini Flashsgr_gemini_pro- SGR with Gemini Prosgr_gpt4o- SGR with GPT-4osgr_gpt4o_mini- SGR with GPT-4o Mini
Note: Other searcher types (ripgrep_claude, agent_claude, agent_gemini_flash_lite, etc.) are experimental implementations from earlier development phases and are not recommended for production use.
Related MCP server: PAMPA
Running the MCP Server
Important: The MCP server is not meant to be run directly in a terminal. It communicates via STDIO using JSON-RPC protocol and must be launched by an IDE or MCP client.
Cursor Configuration
Add to your cursor-mcp-config.json:
{
"mcpServers": {
"qure-semantic-search": {
"command": "/path/to/.venv/bin/qure-semantic-search-mcp",
"env": {
"REPO_PATH": "/path/to/your/repo"
}
}
}
}After configuring, restart Cursor. The server will be automatically launched when you use the semantic_search tool in Cursor's AI chat.
Note: If you see JSON parsing errors when running the command directly in terminal, this is expected - the server requires an MCP client (like Cursor) to communicate with it via JSON-RPC protocol.
Evaluation
Running Evaluation
Standard mode (single run per query):
python -m eval.run_evalStability mode (10 runs per query to measure consistency):
python -m eval.run_eval --stabilityStability mode with custom runs (e.g., 20 runs per query):
python -m eval.run_eval --stability --runs 20Evaluate all searchers (compares different searcher implementations):
python -m eval.run_all_searchers --stabilityAdditional options:
--verbose/-v- Print detailed per-query statistics--single-dataset- Use only main dataset (exclude easy dataset)--output <path>- Export results to JSON file
Datasets
The evaluation uses two datasets:
Main dataset (
data/dataset.jsonl) - 12 challenging examples across different codebases (Django, Gin, CodeQL, QGIS, etc.) with non-trivial queries where simple keyword matching fails.Easy dataset (
data/dataset_easy.jsonl) - 14 simpler examples designed for faster evaluation and testing. These queries are more straightforward but still require semantic understanding.
By default, both datasets are used together (26 queries total). Use --single-dataset to evaluate only the main dataset.
Metrics
For detailed metric definitions and mathematical proof of perfection, see METRICS_LOGIC.md.
Quick Summary:
Precision@K = TP / (TP + FP) - Fraction of returned results that are relevant
Recall@K = TP / (TP + FN) - Fraction of all relevant items that were returned
F1@K = Harmonic mean of Precision and Recall
File Discovery Rate = Files Found / Files Expected
Substring Coverage = Substrings Found / Substrings Required
The Logic Test: If all metrics score 1.0, the solution is mathematically perfect (see proof in METRICS_LOGIC.md).
See eval/metrics.py for detailed implementations.
Performance Results
Evaluation results for sgr_gemini_flash_lite searcher (10 runs per query, 26 queries total):
Overall Performance
Metric | Value | Stability |
Precision@10 | 0.30 ± 0.38 | ⚠ High variance (CV=127%) |
Recall@10 | 0.31 ± 0.41 | ⚠ High variance (CV=133%) |
F1@10 | 0.29 ± 0.38 | ⚠ High variance (CV=130%) |
Success Rate@10 | 0.40 ± 0.46 | ⚠ High variance (CV=114%) |
File Discovery Rate | 0.61 ± 0.40 | ⚠ Moderate variance (CV=66%) |
Substring Coverage | 0.35 ± 0.39 | ⚠ High variance (CV=111%) |
Avg Latency | 20.6s ± 7.9s | Range: 9.6s - 38.3s |
Stability Score | 73.9% | 16/26 stable queries (61.5%) |
Dataset Breakdown
Easy Dataset (14 examples)
Precision@10: 0.40 ± 0.44
Recall@10: 0.46 ± 0.49
F1@10: 0.42 ± 0.45
File Discovery Rate: 0.92 ± 0.13 ✓ (Good stability)
Avg Latency: 15.0s ± 4.8s
Stability Score: 85.9% ✓ (Good stability)
Main Dataset (12 examples)
Precision@10: 0.17 ± 0.25
Recall@10: 0.13 ± 0.18
F1@10: 0.14 ± 0.20
File Discovery Rate: 0.26 ± 0.30
Avg Latency: 27.2s ± 5.3s
Stability Score: 60.0% ⚠ (Moderate stability)
Notes
High variance in metrics is expected due to LLM non-determinism and the complexity of semantic search queries
File Discovery Rate shows better stability, especially on easier queries (92% success rate)
Latency varies significantly (9-38s) depending on query complexity and codebase size
Results are evaluated on non-trivial queries where simple keyword matching fails
Project Structure
src/- Core MCP server and searcher implementationseval/- Evaluation scripts and metricsdata/- Evaluation dataset and test repositoriesscripts/- Utility scripts for testing and debugging
Documentation
METRICS_LOGIC.md - Mathematical justification for metric selection and proof of perfection
KNOWN_ISSUES.md - Current limitations, known problems, and workarounds
FUTURE_ROADMAP.md - Planned improvements and mitigation strategies
Available Tools
1 toolsemantic_searchD
MCP wrapper around core function.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| path | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but fails completely. It doesn't indicate whether this is a read or write operation, what permissions might be needed, whether it has rate limits, what kind of results to expect, or any behavioral characteristics. 'MCP wrapper around core function' reveals nothing about how the tool behaves.
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?
While technically concise (one sentence), this is under-specification rather than effective conciseness. The single sentence 'MCP wrapper around core function' fails to communicate essential information and wastes the opportunity to describe the tool's purpose. True conciseness would deliver necessary information efficiently, not omit it entirely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a semantic search tool with 2 parameters, no annotations, and an output schema (which helps but doesn't excuse the description's inadequacy), this description is completely inadequate. It fails to explain what semantic search means in this context, what's being searched, what the parameters do, or when to use the tool. The presence of an output schema doesn't compensate for these fundamental gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but provides zero parameter information. The description doesn't mention the 'query' or 'path' parameters at all, nor does it explain what they mean, what format they should be in, or how they affect the search. For a tool with 2 parameters (one required), this is a critical omission.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'MCP wrapper around core function' is tautological - it restates that this is a wrapper without specifying what the tool actually does. It provides no verb, resource, or purpose statement. The tool name 'semantic_search' suggests searching with semantic meaning, but the description fails to clarify this.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides absolutely no guidance on when to use this tool. There are no sibling tools mentioned, but even for a standalone tool, there's no context about appropriate use cases, prerequisites, or limitations. The description is completely silent on usage considerations.
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
v0.1.0- First observed
semantic_search
TDQS
Scored across 1 tool
With only one tool, there is no possibility of ambiguity or overlap between tools. The single tool 'semantic_search' has a clear and distinct purpose that cannot be confused with any other tool in the set.
The tool name 'semantic_search' follows a consistent snake_case pattern, and with only one tool, there is no inconsistency to evaluate. The naming is straightforward and matches the server's purpose.
A single tool is generally too few for most server purposes, as it limits functionality and can lead to dead ends in agent workflows. For a semantic search server, one tool feels thin and under-scoped, lacking operations like filtering, indexing, or result management.
The tool set is severely incomplete for a semantic search domain. It only provides a basic search function, with obvious gaps such as indexing documents, managing search indices, updating or deleting entries, or handling advanced search parameters, which are essential for comprehensive semantic search operations.
Maintenance
Related MCP Connectors
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Project memory, semantic code search, and grounded agent context.
Token-efficient search for coding agents over public and private documentation.
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Related MCP Servers
- FlicenseAqualityDmaintenanceEnables AI agents to perform semantic code search across entire codebases using natural language queries. Provides fast indexing and ranked search results with line numbers and file paths through the Seroost search engine.36 npm7-
- AlicenseNot gradedqualityCmaintenanceProvides semantic code search and retrieval capabilities for AI agents, enabling them to query codebases using natural language with automatic learning, hybrid search, and intelligent chunking of functions and classes.13 npm30ISC
- FlicenseNot gradedqualityDmaintenanceEnables AI agents to semantically search and navigate code repositories using natural language, with support for multiple repos, incremental indexing, and no local install needed.-
- AlicenseNot gradedqualityBmaintenanceAdds semantic code search to AI coding agents, enabling natural language queries across entire codebases to retrieve relevant code chunks, saving tokens and providing deep context.16 npm1MIT