R2R FastMCP Server
Click on "Install 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., "@R2R FastMCP Serversearch for recent updates on our project documentation"
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.
R2R FastMCP Server
MCP-сервер для интеграции R2R (Retrieval-Augmented Generation) с Claude Desktop.
Доступные реализации:
server.py— Кастомный MCP сервер с 5 специализированными инструментами (search, rag, advanced_search, graph_search, advanced_rag)r2r_openapi_server.py— Автогенерация из OpenAPI спецификации R2R (полный доступ ко всем R2R API эндпоинтам)
Быстрый старт
# Установка зависимостей через uv
make install
# Настройка окружения
cp .env.example .env
# Отредактируй .env с твоими настройками
# Проверка кода
make lint
# Запуск сервера
make runПримечание: Проект использует
uvдля управления зависимостями. Убедись, что uv установлен:curl -LsSf https://astral.sh/uv/install.sh | sh
Related MCP server: Claude RAG MCP Pipeline
Установка в Claude Desktop
Кастомный сервер (5 инструментов):
# Если возникает ошибка с typer, сначала обнови зависимости:
# pip install --upgrade 'mcp[cli]'
mcp install server.py -v R2R_BASE_URL=http://localhost:7272OpenAPI сервер (полный R2R API):
# Локальная разработка (stdio)
python r2r_openapi_server.py
# Production деплой (HTTP)
uvicorn r2r_openapi_server:app --host 0.0.0.0 --port 8000
# Claude Desktop установка
mcp install r2r_openapi_server.py -v R2R_BASE_URL=http://localhost:7272Доступные инструменты
search— поиск по базе знаний R2R (vector, graph, web, document)rag— RAG-запрос с генерацией ответа
Тестирование с GUI
Для визуального тестирования инструментов используй MCP Inspector:
# Запуск Inspector с веб-интерфейсом
make run-inspectorОткроется браузер на http://localhost:5173 с GUI для:
Просмотра всех 114 инструментов из R2R API
Вызова инструментов с параметрами
Просмотра результатов и логов в реальном времени
Команды разработки
# Установка и управление
make help # Список всех команд
make install # Установка зависимостей
# Проверка кода
make lint # Проверка кода (format + typecheck)
make fix # Автоматическое исправление
# Запуск серверов
make run # Запуск custom MCP server (server.py)
make run-openapi # Запуск OpenAPI MCP server (stdio режим)
make run-http # Запуск OpenAPI MCP server (HTTP режим на :8000)
make run-gemini # Запуск Gemini интеграции (интерактивный)
make run-inspector # Запуск MCP Inspector (GUI для тестирования)
# Утилиты
make clean # Очистка кэшаТребования
Python 3.12+
uv 0.6+ (инструкция по установке)
R2R instance (запущенный сервер)
Документация
Полная документация находится в CLAUDE.md
Available Tools
2 toolsragR2R RAGA
Perform Retrieval-Augmented Generation (RAG) query with full parameter control.
This tool retrieves relevant context from the knowledge base and generates an answer using a language model. Supports all search modes (semantic, hybrid, graph) and customizable generation parameters.
Args: query: The question to answer using the knowledge base. Required. preset: Preset configuration for common use cases. Options: - "default": Basic RAG with gpt-4o-mini, temperature 0.7, 10 results - "development": Hybrid search with higher temperature for creative answers, 15 results - "refactoring": Hybrid + graph search with gpt-4o for code analysis, 20 results - "debug": Minimal graph search with low temperature for precise answers, 5 results - "research": Comprehensive search with gpt-4o for research questions, 30 results - "production": Balanced hybrid search optimized for production, 10 results model: LLM model to use for generation. Examples: - "vertex_ai/gemini-2.5-flash" (default, fast and cost-effective) - "vertex_ai/gemini-2.5-pro" (more capable, higher cost) - "openai/gpt-4-turbo" (high performance) - "anthropic/claude-3-haiku-20240307" (fast) - "anthropic/claude-3-sonnet-20240229" (balanced) - "anthropic/claude-3-opus-20240229" (most capable) temperature: Generation temperature controlling randomness. Must be between 0.0 and 1.0. Lower values (0.0-0.3) = more deterministic, precise answers Medium values (0.4-0.7) = balanced creativity and accuracy (default: 0.7) Higher values (0.8-1.0) = more creative, diverse answers max_tokens: Maximum number of tokens to generate. Optional, uses model default if not specified. use_semantic_search: Enable semantic/vector search for retrieval (default: True) use_hybrid_search: Enable hybrid search combining semantic and full-text search (default: False) use_graph_search: Enable knowledge graph search for entity/relationship context (default: False) limit: Maximum number of search results to retrieve. Must be between 1 and 100 (default: 10) kg_search_type: Knowledge graph search type. "local" for local context, "global" for broader connections (default: "local") semantic_weight: Weight for semantic search in hybrid mode. Must be between 0.0 and 10.0 (default: 5.0) full_text_weight: Weight for full-text search in hybrid mode. Must be between 0.0 and 10.0 (default: 1.0) full_text_limit: Maximum full-text results to consider in hybrid search. Must be between 1 and 1000 (default: 200) rrf_k: Reciprocal Rank Fusion parameter for hybrid search. Must be between 1 and 100 (default: 50) search_strategy: Advanced search strategy (e.g., "hyde", "rag_fusion"). Optional. include_web_search: Include web search results from the internet (default: False) task_prompt_override: Custom system prompt to override the default RAG task prompt. Useful for specializing AI behavior for specific domains or tasks. Optional.
Returns: Generated answer based on relevant context from the knowledge base.
Examples: # Simple RAG query rag("What is machine learning?")
# Development preset for code questions
rag("How to implement async/await in Python?", preset="development")
# Custom RAG with specific model and temperature
rag(
"Explain neural networks",
model="vertex_ai/gemini-2.5-pro",
temperature=0.5
)
# Research preset with comprehensive search
rag(
"Latest developments in transformer architectures",
preset="research"
)
# Debug preset for precise technical answers
rag("What causes this error?", preset="debug")| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| preset | No | default | |
| model | No | vertex_ai/gemini-2.5-pro | |
| temperature | No | ||
| max_tokens | No | ||
| use_semantic_search | No | ||
| use_hybrid_search | No | ||
| use_graph_search | No | ||
| limit | No | ||
| kg_search_type | No | global | |
| semantic_weight | No | ||
| full_text_weight | No | ||
| full_text_limit | No | ||
| rrf_k | No | ||
| search_strategy | No | ||
| include_web_search | No | ||
| task_prompt_override | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, openWorldHint=true, destructiveHint=false, covering basic safety. The description adds valuable context beyond annotations by detailing search modes (semantic, hybrid, graph), generation parameters, and presets for common use cases, though it lacks explicit rate limits or authentication needs.
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 appropriately front-loaded with a clear purpose, but it is lengthy due to extensive parameter details. While informative, some redundancy exists (e.g., repeating defaults in descriptions that are also in the schema), reducing efficiency. Every sentence adds value, but structure could be more streamlined.
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 the tool's high complexity (17 parameters, no schema descriptions, annotations present, output schema exists), the description is highly complete. It covers purpose, usage, detailed parameter semantics, and examples, compensating fully for schema gaps and leveraging annotations for behavioral basics, making it sufficient for agent use.
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?
With 0% schema description coverage for 17 parameters, the description fully compensates by providing detailed explanations for each parameter, including defaults, ranges, options (e.g., preset and model examples), and behavioral effects (e.g., temperature impact). This adds significant meaning beyond the bare schema.
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 clearly states the tool performs 'Retrieval-Augmented Generation (RAG) query' with 'full parameter control,' specifying the verb (perform RAG) and resource (knowledge base). It distinguishes from the sibling 'search' tool by emphasizing generation with an LLM rather than just retrieval.
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 clear context for usage through presets (e.g., 'development' for code questions, 'debug' for precise answers) and examples, but does not explicitly state when to use this tool versus the 'search' sibling tool or other alternatives beyond implied differences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchR2R SearchARead-onlyIdempotent
Perform comprehensive search on R2R knowledge base with full parameter control.
This tool supports semantic search, hybrid search (semantic + full-text), knowledge graph search, and web search. Use presets for common scenarios or customize all parameters manually.
Args: query: The search query to find relevant documents. Required. preset: Preset configuration for common use cases. Options: - "default": Basic semantic search, 10 results - "development": Hybrid search optimized for code development, 15 results - "refactoring": Hybrid + graph search for code refactoring, 20 results - "debug": Minimal graph search for debugging, 5 results - "research": Comprehensive search with global graph, 30 results - "production": Balanced hybrid search for production, 10 results use_semantic_search: Enable semantic/vector search (default: True) use_hybrid_search: Enable hybrid search combining semantic and full-text search (default: False) use_graph_search: Enable knowledge graph search for entity/relationship discovery (default: False) limit: Maximum number of results to return. Must be between 1 and 100 (default: 10) kg_search_type: Knowledge graph search type. "local" for local context, "global" for broader connections (default: "local") semantic_weight: Weight for semantic search in hybrid mode. Must be between 0.0 and 10.0 (default: 5.0) full_text_weight: Weight for full-text search in hybrid mode. Must be between 0.0 and 10.0 (default: 1.0) full_text_limit: Maximum full-text results to consider in hybrid search. Must be between 1 and 1000 (default: 200) rrf_k: Reciprocal Rank Fusion parameter for hybrid search. Must be between 1 and 100 (default: 50) search_strategy: Advanced search strategy (e.g., "hyde", "rag_fusion"). Optional. include_web_search: Include web search results from the internet (default: False)
Returns: Formatted search results including: - Vector search results (chunks) - Graph search results (entities, relationships, communities) - Web search results (if enabled) - Document search results (local documents with chunks)
Examples: # Simple search with default settings search("What is machine learning?")
# Development preset for code search
search("async function implementation", preset="development")
# Custom hybrid search
search(
"API documentation",
use_hybrid_search=True,
semantic_weight=7.0,
limit=20
)
# Research with knowledge graph
search("neural network architectures", preset="research")| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| preset | No | default | |
| use_semantic_search | No | ||
| use_hybrid_search | No | ||
| use_graph_search | No | ||
| limit | No | ||
| kg_search_type | No | local | |
| semantic_weight | No | ||
| full_text_weight | No | ||
| full_text_limit | No | ||
| rrf_k | No | ||
| search_strategy | No | rag_fusion | |
| include_web_search | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond what annotations provide. While annotations declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, the description details the different search modes (semantic, hybrid, graph, web), result formats, and the comprehensive nature of returns. It doesn't contradict annotations and provides rich operational context about search capabilities.
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 well-structured with clear sections (overview, Args, Returns, Examples) but is quite lengthy. While most content is valuable given the complex parameter set, some redundancy exists (e.g., repeating default values that are in the schema). The front-loaded overview is effective, but the overall length could be more concise.
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 the complexity (13 parameters, 0% schema coverage), the description provides complete context. It explains all parameters in detail, includes return format information (though an output schema exists), provides multiple usage examples, and covers the tool's comprehensive capabilities. For a complex search tool with rich functionality, this description leaves few 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?
With 0% schema description coverage for 13 parameters, the description carries the full burden of parameter documentation and excels at this. It provides detailed explanations for all parameters including query, preset options with descriptions, boolean flags with defaults, numeric ranges, and advanced options. The 'Args' section comprehensively documents what each parameter does beyond the bare schema.
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 clearly states the tool performs 'comprehensive search on R2R knowledge base with full parameter control' and mentions semantic, hybrid, graph, and web search capabilities. It distinguishes from the sibling 'rag' tool by focusing on search rather than retrieval-augmented generation. However, it doesn't explicitly contrast with 'rag' beyond the different verb focus.
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 good usage guidance with 'Use presets for common scenarios or customize all parameters manually' and includes multiple examples showing different use cases. It doesn't explicitly state when to use this vs the 'rag' sibling tool, but the presets (development, refactoring, debug, research, production) suggest appropriate contexts for this search tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TDQS
The two tools have significant functional overlap and ambiguous boundaries. Both 'rag' and 'search' perform retrieval from the knowledge base with nearly identical search parameters and presets, differing mainly in that 'rag' includes LLM generation while 'search' returns raw results. This overlap could easily cause misselection, as agents might struggle to choose between them for retrieval-focused tasks.
Tool names follow a perfectly consistent pattern with simple, descriptive verbs ('rag' and 'search') in lowercase. Both names clearly indicate their primary function without mixing conventions, making them predictable and easy to understand within the server's scope.
With only 2 tools, the server feels severely under-scoped for a RAG/knowledge base system. While the tools are feature-rich individually, the set lacks basic operations like knowledge base management (e.g., add/remove documents), configuration updates, or status checks. This minimal count limits agent workflows and suggests an incomplete surface.
The tool surface has significant gaps for a RAG server. There are no tools for managing the knowledge base (ingesting, updating, or deleting documents), monitoring system status, or configuring core settings. While 'rag' and 'search' cover querying comprehensively, the absence of management operations creates dead ends for agents needing to interact with the underlying data.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Search your knowledge bases from any AI assistant using hybrid RAG.
Connect your team's living knowledge base — docs, data, issues, CRM — to Claude and ChatGPT.
Ingest, manage, and retrieve documents for RAG-powered AI applications
Self-hosted AI-native knowledge workspace with hybrid search, GraphRAG, and MCP.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceIntegrates Claude Desktop with Azure AI Search, allowing users to query search indexes using keyword, vector, or hybrid search methods.55
- AlicenseNot gradedqualityDmaintenanceEnables Claude Desktop to search and query personal document collections (PDF, Word, Markdown, text) using semantic search and conversational AI with full context preservation across exchanges.MIT
- AlicenseNot gradedqualityCmaintenanceEnables building production-grade RAG systems with agentic reasoning, hybrid retrieval, and MCP protocol integration for use with Claude Desktop.1MIT
- FlicenseNot gradedqualityDmaintenanceEnables Claude Desktop to query a local Zendesk Help Center knowledge graph for semantic search, article retrieval, content gap analysis, and editorial intelligence tasks.3
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/evgenygurin/r2r-rag-search-agent'
If you have feedback or need assistance with the MCP directory API, please join our Discord server