RAGFlow Claude MCP Server
Servidor MCP de RAGFlow para Claude
Un pequeño servidor de Model Context Protocol (MCP) que conecta Claude Desktop (y otros clientes MCP) a una instancia de RAGFlow. Expone la API REST de RAGFlow como un conjunto de herramientas para que el LLM pueda consultar bases de conocimientos y extraer fragmentos de documentos en su contexto.
Este es un software de uso personal que escribí para mi propia I+D. No está libre de errores y el código no es elegante. Funciona para lo que necesito.
Qué hace
Recuperación directa: extrae fragmentos de documentos sin procesar con puntuaciones de similitud desde el endpoint
/retrievalde RAGFlow.Búsqueda en múltiples KB: una sola consulta puede acceder a varias bases de conocimientos a la vez.
Profundización de consultas con DSPy: refinamiento iterativo de consultas opcional (utiliza un LLM para analizar resultados intermedios y reescribir la consulta).
~~Reclasificación (Reranking)~~ — actualmente roto en el lado de RAGFlow, ver Problemas conocidos.
Control de resultados ajustable:
page_size,similarity_threshold,top_k, paginación.Filtro de documentos: limita los resultados a un documento dentro de un conjunto de datos (coincidencia difusa de nombres).
Búsqueda de conjuntos de datos por nombre (sin distinción entre mayúsculas y minúsculas, difusa) en lugar de por ID.
Autenticación Cloudflare Zero Trust cuando su RAGFlow se encuentra detrás de ella.
Related MCP server: RAGBrain MCP
Instalación
Clonar:
git clone https://github.com/norandom/ragflow-claude-desktop-local-mcp cd ragflow-claude-desktop-local-mcpInstalar:
# On macOS, install DSPy first to dodge build issues: pip install git+https://github.com/stanfordnlp/dspy.git uv installConfigurar: copie la muestra y rellene sus detalles de RAGFlow.
cp config.json.sample config.jsonClaves:
RAGFLOW_BASE_URL: ej.http://your-ragflow-server:9380RAGFLOW_API_KEY: su clave API de RAGFlowRAGFLOW_DEFAULT_RERANK: modelo de reclasificación (por defectorerank-multilingual-v3.0)CF_ACCESS_CLIENT_ID(opcional): ID de token de servicio de Cloudflare Zero TrustCF_ACCESS_CLIENT_SECRET(opcional): secreto de token de servicio de Cloudflare Zero TrustDSPY_MODEL: LM de DSPy (por defectoopenai/gpt-4o-mini)OPENAI_API_KEY: necesario para la profundización con DSPy
Cloudflare Zero Trust
Si su RAGFlow está detrás de Cloudflare Zero Trust, obtenga un token de servicio del panel de control y añádalo a config.json:
{
"CF_ACCESS_CLIENT_ID": "your-client-id.access",
"CF_ACCESS_CLIENT_SECRET": "your-client-secret"
}Cuando ambos están configurados, cada solicitud de API se envía con los encabezados CF-Access-Client-Id y CF-Access-Client-Secret. No se requiere ningún cambio en el código.
Configuración de Claude Desktop
{
"mcpServers": {
"ragflow": {
"command": "uv",
"args": [
"run",
"--directory",
"/path/to/ragflow-claude-desktop-local-mcp",
"ragflow-claude-mcp"
]
}
}
}Herramientas
ragflow_retrieval_by_name (la que más uso)
Recupera fragmentos a través de uno o más conjuntos de datos por nombre. Devuelve fragmentos sin procesar con puntuaciones de similitud.
Parámetros:
dataset_names(obligatorio) — lista, ej.["BASF", "Quant Literature"]query(obligatorio)document_name(opcional) — restringir a un documento; coincidencia difusatop_k(opcional, por defecto 1024) — candidatos vectorialessimilarity_threshold(opcional, por defecto 0.2) — 0.0–1.0page(opcional, por defecto 1)page_size(opcional, por defecto 10)use_rerank(opcional, por defecto false) — actualmente roto en el origen, ver Problemas conocidosdeepening_level(opcional, por defecto 0) — refinamiento con DSPy, 0–3
ragflow_retrieval
La misma forma, pero toma dataset_ids: List[str] en lugar de nombres.
Búsqueda en múltiples KB
Puede buscar en varias bases de conocimientos en una sola llamada. Asegúrese de que compartan un modelo de incrustación (embedding): mezclar incrustaciones incompatibles arruinará las puntuaciones de relevancia.
Use ragflow_retrieval_by_name with dataset_names ["Finance Reports", "Legal Documents"] and query "Summarize the key financial risks and compliance requirements for new market entry."ragflow_list_datasets
Enumera todas las bases de conocimientos en su instancia de RAGFlow. Sin parámetros. Recorre todas las páginas internamente.
ragflow_list_documents
Enumera los documentos en un conjunto de datos. Recorre todas las páginas.
dataset_id(obligatorio)
ragflow_get_chunks
Devuelve fragmentos (con referencias) para un documento.
dataset_id(obligatorio)document_id(obligatorio)
ragflow_list_sessions
Muestra las sesiones de chat activas por conjunto de datos. Sin parámetros.
ragflow_list_documents_by_name
Enumera los documentos en un conjunto de datos, buscados por nombre.
dataset_name(obligatorio)
ragflow_reset_session
Elimina la sesión de chat para un conjunto de datos.
dataset_id(obligatorio)
Ajuste de la recuperación
Las herramientas de recuperación tienen tres controles:
page_size— fragmentos por página (por defecto 10).similarity_threshold— descarta fragmentos por debajo de esta puntuación (por defecto 0.2).top_k— tamaño del grupo para la búsqueda vectorial antes del filtrado (por defecto 1024).
Algunos puntos de partida que me funcionan:
Recuperación más amplia:
page_size=15,similarity_threshold=0.15.Precisión estricta:
page_size=5,similarity_threshold=0.4.Investigación profunda:
page_size=20,similarity_threshold=0.1,deepening_level=1.Consultas difíciles:
deepening_level=2.Velocidad: mantenga
deepening_level=0y omita la reclasificación.
Ejemplos
Recuperación básica por nombre:
Use ragflow_retrieval_by_name with dataset_names ["BASF"] and query "What is BASF's latest income statement? Revenue, operating income, net income, and other key figures."Restringir a un documento:
Use ragflow_retrieval_by_name with dataset_names ["BASF"], document_name "annual_report_2023", and query "What were the key financial highlights for 2023?"Los nombres de los documentos coinciden de forma difusa: "annual" coincidirá con annual_report_2023.pdf y annual_report_2024.pdf. Cuando coinciden varios, el servidor elige el más reciente y enumera las alternativas en los metadatos de respuesta.
Profundización con DSPy para una consulta complicada:
Use ragflow_retrieval_by_name with dataset_names ["Quant Literature"], query "what is a volatility clock", deepening_level 2.Varias páginas:
Use ragflow_retrieval_by_name with dataset_names ["BASF"], query "BASF business segments", page_size 10, page 2.Listar lo que está disponible:
Use ragflow_list_datasets.Use ragflow_list_documents_by_name with dataset_name "BASF".Extraer fragmentos específicos:
Use ragflow_get_chunks with dataset_id "43066ee0599411f089787a39c10de57b" and document_id "d74a1c105a3311f09fc94a0fcd8b7722".Prompts más grandes
Algunos ejemplos de cómo lo manejo desde Claude Desktop.
Análisis financiero profundo:
Help me analyse BASF's recent financials.
1. Use ragflow_retrieval_by_name to search ["BASF"] for the latest income statement
(revenue, operating income, net income). Use page_size 15,
similarity_threshold 0.15, deepening_level 1.
2. Then run ragflow_retrieval_by_name again for the cash flow statement,
page_size 10, similarity_threshold 0.2.
3. Finally look for year-over-year changes with page_size 12,
similarity_threshold 0.18.Investigación multilingüe:
Use ragflow_retrieval_by_name with dataset_names ["BASF"],
query "Was sind die wichtigsten Geschäftsbereiche von BASF?",
deepening_level 2.DSPy detecta el idioma de la consulta y lo refina en consecuencia. Lo he usado para consultas en alemán, inglés y en idiomas mixtos. Funciona siempre que los documentos subyacentes tengan contenido en esos idiomas.
Investigación filtrada por documento:
1. Use ragflow_list_documents_by_name with dataset_name "BASF" to see what's in there.
2. Use ragflow_retrieval_by_name with dataset_names ["BASF"],
document_name "sustainability_report", query "carbon neutrality goals",
page_size 15, deepening_level 1.
3. Follow up with document_name "annual_report_2023" and
query "environmental investments".Consulta entre KB:
Use ragflow_retrieval_by_name with dataset_names ["BASF", "Industry Reports"],
query "chemical industry sustainability benchmarks",
page_size 12, deepening_level 1.Cómo funciona la profundización de DSPy
deepening_level ejecuta un bucle de refinamiento impulsado por LLM sobre la recuperación:
0: sin profundización (por defecto).
1: una pasada de refinamiento.
2: dos pasadas con análisis de brechas.
3: tres o más pasadas más fusión de resultados.
Cada pasada: realizar la búsqueda, resumir los mejores resultados, preguntar al LLM qué falta, generar una nueva consulta, ejecutarla. Los metadatos de respuesta incluyen la consulta original, cada consulta refinada y el razonamiento en cada paso.
DSPy necesita:
DSPY_MODEL—openai/gpt-4o-minifunciona bienOPENAI_API_KEY
Reclasificación (actualmente rota)
Cuando funciona, la reclasificación reemplaza la puntuación de coseno vectorial con la puntuación del modelo de reclasificación (típicamente un 10-30% mejor de relevancia en mi experiencia). RAGFlow tiene un error conocido en este momento donde use_rerank=true produce:
UnsupportedProtocol: Request URL is missing an 'http://' or 'https://' protocol
Así que deje use_rerank=false hasta que se solucione el problema en el origen. La recuperación vectorial estándar funciona normalmente.
Cómo funciona la búsqueda de conjuntos de datos
Coincidencia de nombres sin distinción entre mayúsculas y minúsculas.
Coincidencia difusa para nombres parciales.
Los conjuntos de datos se almacenan en caché para la búsqueda de nombres; los fallos de caché activan una actualización.
Si la búsqueda falla, el error incluye los nombres de los conjuntos de datos disponibles para que sepa qué había realmente allí.
Coincidencia de documentos
Cuando pasa document_name:
La coincidencia exacta gana, luego "comienza con", luego "contiene", luego parcial.
En caso de empate, gana el documento actualizado más recientemente.
Los nombres que contienen
2024,2023,latest,currentonewobtienen una pequeña bonificación de puntuación.Todas las coincidencias se devuelven en los metadatos de respuesta para que pueda volver a emitir con un nombre más específico.
Manejo de errores
Mensajes de error razonables para: errores de API, conjuntos de datos faltantes, RAGFlow inalcanzable, sesiones rotas, entrada no válida y problemas de configuración. Los valores sensibles se ocultan en los registros.
Variables de entorno
RAGFLOW_BASE_URL— anula el archivo de configuración. Por defecto en el código:http://192.168.122.93:9380(que es mi instancia local).RAGFLOW_API_KEY— obligatorio.
Desarrollo
Ejecute el servidor directamente:
uv run ragflow-claude-mcpEscucha en stdio, como hacen los servidores MCP.
Dependencias de desarrollo:
uv install --extra devEso obtiene pytest + los complementos asyncio/mock/cov.
Pruebas:
uv run pytest
uv run pytest --cov=src --cov-report=html --cov-report=term
uv run pytest tests/test_server.py
uv run pytest -vLa cobertura es de alrededor del 44% con 22/23 pruebas pasando (una se omite debido a un fallo intermitente de CI). Las pruebas cubren la inicialización del servidor, la integración de la API de RAGFlow, la profundización de DSPy, las ramas de configuración de OpenAI/OpenRouter y la carga de configuración.
Notas de implementación
La API de recuperación es la única superficie de RAGFlow en la que realmente se basa el servidor. Sin dependencias de asistente/chat, sin configuración de prompt del lado del servidor: solo fragmentos de vuelta. Más fácil de razonar, más fácil de depurar.
Solución de problemas
"Dataset not found": ejecute
ragflow_list_datasetspara ver qué hay realmente allí.Errores de conexión: verifique
RAGFLOW_BASE_URLyRAGFLOW_API_KEY.El servidor no arranca: ¿terminó realmente
uv install?Necesita fragmentos sin procesar: eso es
ragflow_retrieval_by_name/ragflow_retrieval.Sesión bloqueada:
ragflow_list_sessionsy luegoragflow_reset_session.403 de Cloudflare: confirme que
CF_ACCESS_CLIENT_ID/CF_ACCESS_CLIENT_SECRETcoinciden con un token de servicio activo en la aplicación Zero Trust.
Problemas conocidos
La reclasificación está rota en el origen
use_rerank=true da error con UnsupportedProtocol: Request URL is missing an 'http://' or 'https://' protocol. Este es un defecto del lado de RAGFlow. Solución: déjelo desactivado. Estoy atento al repositorio de RAGFlow para una solución.
Contribución
Solo PRs: main está protegido. Los commits deben estar firmados con SSH.
Bifurcar (Fork).
git checkout -b feature/your-thing.Realice el cambio, escriba un mensaje de commit claro.
Envíe a su bifurcación.
Abra un PR contra
main.
Los PRs ejecutan TruffleHog automáticamente: no incluya claves, tokens o secretos. Consulte CONTRIBUTING.md para la versión más larga.
Available Tools
8 toolsragflow_get_chunksC
Get chunks with references from a specific document
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes | ID of the dataset | |
| document_id | Yes | ID of the document to get chunks from |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states a simple data retrieval. It omits important traits like pagination, rate limits, authentication, or potential side effects, leaving the agent under-informed.
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, but it is overly brief and lacks important details. Conciseness is not valuable at the expense of completeness.
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 absence of an output schema, the description should explain what 'chunks with references' means and the format of the return value. It does not, leaving the agent with insufficient context for a simple tool.
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 100%, so the schema already documents both parameters. The description does not add meaning beyond what the schema provides, earning a baseline score of 3.
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 action ('Get') and the resource ('chunks with references from a specific document'), effectively distinguishing it from sibling tools like listing datasets or retrieval. However, 'references' could be more explicit.
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?
No guidance is provided on when to use this tool versus alternatives such as retrieval tools. There is no mention of prerequisites, context, or situations where this tool is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ragflow_list_datasetsA
List all available datasets/knowledge bases in RAGFlow
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states 'list all available' but omits details like pagination, ordering, or side effects. Adequate but minimal.
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?
Single sentence, front-loaded with action. No wasted words.
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?
While sufficient for a zero-parameter listing tool, the lack of output schema leaves the agent uninformed about the response structure, which could be improved.
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?
No parameters exist, and schema coverage is 100%. Baseline 4 applies as the description adds no parameter info, which is acceptable.
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 action ('List'), the resource ('all available datasets/knowledge bases'), and distinguishes it from siblings which deal with chunks, documents, and sessions.
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?
No explicit guidance on when to use this tool versus siblings. The description only states what it does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ragflow_list_documentsC
List documents in a specific dataset
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes | ID of the dataset to list documents from |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses no behavioral traits such as read-only nature, pagination, error handling, or side effects.
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 extremely concise and front-loaded, stating the core purpose in a single phrase with no extraneous content.
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 no output schema and no annotations, the description fails to cover return format, pagination, or error conditions, even for a simple list tool it feels incomplete.
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% with a description for the single parameter. The tool description adds no additional meaning beyond what the schema already provides.
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 verb 'List', resource 'documents', and context 'in a specific dataset'. It distinguishes from siblings such as ragflow_list_datasets (lists datasets) and ragflow_get_chunks (gets chunks).
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?
No guidance on when to use or not use this tool versus alternatives. The description only states the basic action without any contextual hints or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ragflow_list_documents_by_nameC
List documents in a dataset by dataset name
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_name | Yes | Name of the dataset/knowledge base to list documents from |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source for behavioral clues. It implies a read operation but does not disclose details such as pagination, authentication requirements, rate limits, or what the response looks like. Minimal transparency.
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?
Single sentence, front-loaded with key action and resource. Efficient but could benefit from additional context without being verbose.
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 no output schema, the description should hint at what the returned list contains (e.g., document names, IDs, metadata). It only states what it does, not what the agent gets back. Missing return value details.
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 baseline is 3. The description only restates the parameter's purpose ('by dataset name') which is already described in the schema. Adds no extra meaning.
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?
Description clearly states the action (List), resource (documents), and filter (by dataset name). It is specific and suggests the tool's scope, but does not explicitly differentiate from the sibling tool 'ragflow_list_documents' which likely lists documents without a dataset name filter.
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?
No guidance on when to use this tool versus the sibling 'ragflow_list_documents', which might list all documents or use different criteria. The description does not mention alternatives or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ragflow_list_sessionsB
List active chat sessions for all datasets
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It only says 'List active chat sessions' but does not explain what 'active' means, any side effects, or limitations. Minimal behavioral disclosure.
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?
A single, direct sentence with no wasted words. It is front-loaded with the key action and resource.
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?
Despite no parameters, the description lacks details on output format, pagination, or what constitutes an active session. Without output schema or annotations, the description is insufficient for complete understanding.
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?
The input schema is empty (0 parameters), so schema coverage is 100%. The description adds meaning by specifying the resource and scope, which is beyond the empty schema. Baseline 3, but the context provided justifies a higher score.
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 verb 'List' and the resource 'active chat sessions' with scope 'for all datasets', distinguishing it from sibling tools like ragflow_list_datasets.
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?
No guidance on when to use this tool over alternatives like ragflow_list_datasets or ragflow_reset_session. The description only states what it does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ragflow_reset_sessionB
Reset/clear the chat session for a specific dataset
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes | ID of the dataset to reset session for |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description merely states the action without disclosing side effects (e.g., whether session history is deleted permanently, if it affects other datasets, or if confirmation is required).
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?
Single sentence, 10 words, no redundancy. Front-loaded with verb and resource. Efficiently communicates the core function.
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?
Adequate for a simple reset action with one parameter and no output schema, but lacks behavioral details that would help the agent understand consequences. Could mention that the session is cleared without confirmation or return value.
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% for one parameter. Description mirrors the schema's description ('ID of the dataset to reset session for') without adding new meaning or constraints.
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?
Description clearly states the action (reset/clear) and the resource (chat session for a specific dataset). It is distinct from sibling tools which are for listing or retrieval, not mutation.
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?
No guidance on when to use this tool versus alternatives. Does not mention prerequisites, conditions, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ragflow_retrievalB
Retrieve document chunks directly from RAGFlow datasets using the retrieval API. Returns raw chunks with similarity scores.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination. Defaults to 1. | |
| query | Yes | Search query or question | |
| top_k | No | Number of chunks for vector cosine computation. Defaults to 1024. | |
| page_size | No | Number of chunks per page. Defaults to 10. | |
| use_rerank | No | Whether to enable reranking for better result quality. Default: false (uses vector similarity only). | |
| dataset_ids | Yes | List of IDs of the datasets/knowledge bases to search | |
| document_name | No | Optional document name to filter results to specific document | |
| deepening_level | No | Level of DSPy query refinement (0-3). 0=none, 1=basic refinement, 2=gap analysis, 3=full optimization. Default: 0 | |
| similarity_threshold | No | Minimum similarity score for chunks (0.0 to 1.0). Defaults to 0.2. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits like whether the tool is read-only, permission requirements, or pagination behavior. It only says 'Returns raw chunks' and does not address these aspects, leaving the agent with incomplete understanding of its side effects or constraints.
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 succinct: two sentences that convey the core function and output without extraneous words. It is front-loaded and efficient.
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 has 9 parameters and no output schema, the description should provide more context on how to use parameters like deepening_level or use_rerank, and what the returned chunks contain. It states 'raw chunks with similarity scores' but lacks detail on the structure of the response, which is necessary for an agent to process the output correctly.
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. The description does not add meaning beyond what the parameter descriptions already provide (e.g., page, top_k). It mentions 'similarity scores' but does not clarify how parameters like similarity_threshold relate to the output.
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 verb 'Retrieve' and the resource 'document chunks' from RAGFlow datasets, and specifies the output as 'raw chunks with similarity scores'. However, it does not explicitly differentiate from sibling tools like ragflow_retrieval_by_name, which likely performs a similar function.
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 no guidance on when to use this tool versus alternatives such as ragflow_get_chunks or ragflow_retrieval_by_name. It merely states what the tool does, without context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ragflow_retrieval_by_nameB
Retrieve document chunks by dataset names using the retrieval API. Returns raw chunks with similarity scores.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination. Defaults to 1. | |
| query | Yes | Search query or question | |
| top_k | No | Number of chunks for vector cosine computation. Defaults to 1024. | |
| page_size | No | Number of chunks per page. Defaults to 10. | |
| use_rerank | No | Whether to enable reranking for better result quality. Default: false (uses vector similarity only). | |
| dataset_names | Yes | List of names of the datasets/knowledge bases to search (e.g., ['BASF', 'Legal']) | |
| document_name | No | Optional document name to filter results to specific document | |
| deepening_level | No | Level of DSPy query refinement (0-3). 0=none, 1=basic refinement, 2=gap analysis, 3=full optimization. Default: 0 | |
| similarity_threshold | No | Minimum similarity score for chunks (0.0 to 1.0). Defaults to 0.2. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions return type (raw chunks with similarity scores) but lacks information on side effects, permissions, rate limits, or destructive potential. 'Retrieve' implies read-only but is not explicit.
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, front-loading the purpose. It is efficient but could be slightly more structured without adding verbosity.
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?
With 9 parameters and no output schema, the description is sparse. It omits details on pagination, reranking, deepening_level, and similarity_threshold behavior, leaving the agent to rely solely on the schema for context.
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 100%, so baseline is 3. The description adds minimal meaning beyond the schema, only briefly noting retrieval by dataset names and return format. No parameter interaction hints are provided.
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 verb (retrieve), resource (document chunks), and distinguishing parameter (by dataset names). It differentiates from siblings like ragflow_retrieval which likely uses different criteria.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies usage with dataset names but does not mention exclusions or compare to ragflow_retrieval or other search methods.
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.
8 tool updates
v0.1.0- First observed
ragflow_get_chunks - First observed
ragflow_list_datasets - First observed
ragflow_list_documents - First observed
ragflow_list_documents_by_name - First observed
ragflow_list_sessions - First observed
ragflow_reset_session - First observed
ragflow_retrieval - First observed
ragflow_retrieval_by_name
TDQS
Scored across 8 tools
Most tools have distinct purposes, but ragflow_list_documents and ragflow_retrieval each have an alternative by-name variant, which could cause confusion if descriptions are not heeded. However, descriptions clarify the difference between ID-based and name-based operations, keeping overlap minimal.
All tools follow a consistent verb_noun pattern with snake_case and the 'ragflow_' prefix. Variations like '_by_name' are systematic and predictable, enhancing readability for agents.
With 8 tools, the set is well-scoped for a knowledge base retrieval server. Each tool serves a clear function, and the count is neither too sparse nor overwhelming for the intended purpose.
The tool surface covers listing datasets, listing documents, retrieving chunks, and managing chat sessions. It lacks create/update/delete operations, but given the likely read-heavy focus of the server, these gaps are acceptable and do not impede the primary retrieval workflow.
Maintenance
Related MCP Connectors
Connect your team's living knowledge base — docs, data, issues, CRM — to Claude and ChatGPT.
Cloud or self-hosted knowledge for AI agents: hybrid search, reranking, GraphRAG, scoped MCP tools.
Ingest, manage, and retrieve documents for RAG-powered AI applications
Search your knowledge bases from any AI assistant using hybrid RAG.
Related MCP Servers
- FlicenseAqualityDmaintenanceIntegrates R2R (Retrieval-Augmented Generation) with Claude Desktop, enabling semantic search across knowledge bases and RAG-based question answering with support for vector, graph, web, and document search.2-
- AlicenseAqualityFmaintenanceConnects Claude Desktop to a RAGBrain knowledge base to enable semantic search, document retrieval, and namespace management. It allows users to browse collections, discover documents by topic, and access full text content through natural language.5MIT
- AlicenseAqualityDmaintenanceProvides semantic search capabilities by connecting Claude Desktop to a Cloudflare Workers backend powered by Vectorize. It enables natural language querying of knowledge bases using vector similarity and edge-based embedding generation.2MIT
- AlicenseNot gradedqualityDmaintenanceEnables semantic retrieval and knowledge base management through the RAGFlow API, including dataset, document, chunk, chat, and graph operations.5MIT