SignalRank MCP
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., "@SignalRank MCPsearch for 'llm evaluation metrics' with hybrid mode"
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.
SignalRank MCP
MCP interface for SignalRank retrieval.
SignalRank MCP is a thin interoperability layer over SignalRank-RAG.
It exposes SignalRank retrieval to MCP-compatible clients without duplicating retrieval or ranking logic.
MCP client / host
│
▼
SignalRank MCP
│ authenticated HTTP
▼
SignalRank-RAGTool
search
Search SignalRank and return ranked evidence with provenance.
search(query, mode="dense", top_k=5)Supported retrieval modes:
bm25
dense
hybridResults preserve:
chunk_id
doc_id
text
score
rank
source_path
metadataRelated MCP server: mcp-rag-search
Install
git clone https://github.com/bksampadi/signalrank-mcp.git
cd signalrank-mcp
uv sync --extra devEnvironment
SignalRank-RAG must be running.
Set the same service token for SignalRank-RAG and SignalRank MCP:
SIGNALRANK_SERVICE_TOKEN=signalrank-local-devSignalRank-RAG also requires:
GROQ_API_KEY=<your-groq-api-key>SignalRank MCP defaults to:
SIGNALRANK_API_URL=http://127.0.0.1:8000Do not commit API keys or production service tokens.
Run
Start SignalRank-RAG:
uv run uvicorn signalrank.api.main:app --host 127.0.0.1 --port 8000Run with MCP Inspector:
uv run mcp dev src/signalrank_mcp/server.py --with-editable .Or run directly over stdio:
uv run signalrank-mcpClaude Code
Register the server:
claude mcp add --env SIGNALRANK_SERVICE_TOKEN=signalrank-local-dev --transport stdio signalrank -- uv run signalrank-mcpCheck the connection:
claude mcp get signalrankTest
uv run pytest -q
uv run ruff check .
uv run pyrightTested end-to-end with MCP Inspector and Claude Code.
License
MIT
Available Tools
1 toolsearchA
Search SignalRank and return ranked evidence without LLM synthesis.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | dense | |
| query | Yes | ||
| top_k | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| mode | Yes | |
| query | Yes | |
| results | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses a key behavioral trait: the tool does NOT perform LLM synthesis, returning raw ranked evidence. This is valuable. However, it doesn't disclose other behaviors like whether it's read-only, rate limits, or what the output structure looks like. The output schema exists, so return format is covered, but the description could add more context about the nature of the evidence.
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?
The description is a single sentence with no wasted words. It front-loads the action and resource, then adds the key differentiator. Every word earns its place.
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?
The tool has 3 parameters, an output schema, and no annotations. The description explains the core purpose and the 'no synthesis' behavior, but doesn't explain the mode parameter or provide guidance on when to use each mode. The output schema covers return values, but the description is incomplete for a tool with 0% schema coverage and no annotations.
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. The description mentions 'ranked evidence' which implies the top_k parameter's purpose, and 'Search' implies the query parameter. However, it doesn't explain the 'mode' parameter (bm25, dense, hybrid) at all. The description adds some meaning but leaves the mode parameter unexplained, which is a significant gap.
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 states a specific verb ('Search'), a specific resource ('SignalRank'), and a key differentiator ('return ranked evidence without LLM synthesis'). This clearly distinguishes it from a typical LLM-based search or synthesis tool. It could be slightly more explicit about what 'SignalRank' is, but the core purpose is clear.
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 implies usage: use this when you want raw ranked evidence, not synthesized answers. However, it doesn't explicitly state when to use it vs alternatives, and there are no sibling tools listed. The 'without LLM synthesis' phrase provides some context but doesn't fully guide an agent on when to choose this over other tools.
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
search
TDQS
Scored across 1 tool
Only one tool exists, so there is no risk of selecting between overlapping operations. The single 'search' tool has a clear, singular purpose.
The tool name 'search' is a clear, conventional verb, but with only one tool there is no broader verb_noun or convention pattern to evaluate. No inconsistency is present, though the naming style cannot be fully assessed.
A single search tool forms a thin but functionally valid server for ranked-evidence lookup. It is at the low end of acceptable scope and may leave agents wanting supplementary operations.
The search operation covers the core retrieval use case, but the one-tool surface offers no way to fetch evidence by ID, filter results independently, or inspect sources. Secondary workflows may therefore dead-end.
Maintenance
Related MCP Connectors
Agent-driven search: build, import, tune, search, and score result quality — all over MCP.
Multi-engine search for AI agents. Trust scoring, local corpus, MCP-native. Self-hostable, BYOK.
Agentic search over your Dewey document collections from any MCP-compatible client.
Search and monitor source-backed AI agent ecosystem signals, briefings, deltas, and source health.
Related MCP Servers
- AlicenseNot gradedqualityBmaintenanceProvides hybrid retrieval (dense + BM25 + RRF) with collection-based isolation and document ingestion for private knowledge access via MCP.MIT
- FlicenseNot gradedqualityCmaintenanceEnables agent tools like Claude Code and GitHub Copilot to perform knowledge retrieval using hybrid search (BM25 + dense) with reranking, via MCP protocol.-
- AlicenseNot gradedqualityCmaintenanceEnables MCP clients to query a modular RAG knowledge hub with hybrid dense/sparse retrieval, reranking, multimodal image support, and traceable observability, all through natural language tools.MIT
- AlicenseAqualityBmaintenanceEnables any MCP host to search and answer over your own documents with hybrid BM25+dense retrieval, cross-encoder reranking, and grounded, cited responses that refuse when no evidence is found.5MIT