RAGFlow MCP Server
Allows interaction with RAGFlow knowledge bases and chat through GitHub Copilot via the MCP protocol.
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., "@RAGFlow MCP Serverlist all datasets"
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.
RAGFlow MCP Server
RAGFlow API MCP Server,可以查找知识库和聊天。
下载 MCP 开发文档和 RAGFlow API 参考:
wget https://modelcontextprotocol.io/llms-full.txt -O docs/mcp-llms-full.txt
wget https://github.com/infiniflow/ragflow/raw/refs/heads/main/docs/references/python_api_reference.md -O docs/ragflow-python_api_reference.mdComponents
Tools
list_datasets
列出所有数据集
返回数据集的 ID 和名称
create_chat
创建一个新的聊天助手
输入:
name: 聊天助手的名称
dataset_id: 数据集的 ID
返回创建的聊天助手的 ID、名称和会话 ID
chat
与聊天助手进行对话
输入:
session_id: 聊天助手的会话 ID
question: 提问内容
返回聊天助手的回答
Related MCP server: RAGFlow MCP Server
Configuration
[TODO: Add configuration details specific to your implementation]
Quickstart
Install
GitHub Copilot
.vscode/mcp.json
{
"servers": {
"ragflow-mcp-server": {
"command": "uvx",
"args": [
"ragflow-mcp-server",
"--api-key=ragflow-dhMzViYzJlMTM1NjExZjBiNWU5MDI0Mm",
"--base-url=http://172.16.33.66:8060"
]
}
}
}Continue
config.yaml
mcpServers:
- name: RAGFlow Server
command: uvx
args:
- ragflow-mcp-server
- --api-key
- ragflow-dhMzViYzJlMTM1NjExZjBiNWU5MDI0Mm
- --base-url
- http://172.16.33.66:8060Claude Desktop
On MacOS: ~/Library/Application\ Support/Claude/claude_desktop_config.json
On Windows: %APPDATA%/Claude/claude_desktop_config.json
Development
Building and Publishing
To prepare the package for distribution:
Sync dependencies and update lockfile:
uv syncBuild package distributions:
uv buildThis will create source and wheel distributions in the dist/ directory.
Publish to PyPI:
uv publishNote: You'll need to set PyPI credentials via environment variables or command flags:
Token:
--tokenorUV_PUBLISH_TOKENOr username/password:
--username/UV_PUBLISH_USERNAMEand--password/UV_PUBLISH_PASSWORD
Debugging
Since MCP servers run over stdio, debugging can be challenging. For the best debugging experience, we strongly recommend using the MCP Inspector.
You can launch the MCP Inspector via npm with this command:
npx @modelcontextprotocol/inspector \
uv --directory /Users/junjian/GitHub/wang-junjian/ragflow-mcp-server \
run ragflow-mcp-server \
--api-key ragflow-dhMzViYzJlMTM1NjExZjBiNWU5MDI0Mm \
--base-url http://172.16.33.66:8060Upon launching, the Inspector will display a URL that you can access in your browser to begin debugging.
Available Tools
3 toolschat聊天C
向聊天助手提问
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | 聊天会话ID | |
| question | Yes | 提问的问题 |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It doesn't disclose what happens after asking (e.g., returns an answer), any side effects, or idempotency. Simply says 'ask'.
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 one short sentence, which is concise but under-specified. It could be slightly longer to include key details 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 only two parameters and no output schema, the description should clarify that it returns a response and requires an existing session. It lacks this information, making it incomplete for an agent.
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% (both parameters described). The description adds no extra meaning beyond schema, so baseline 3 is appropriate.
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 'ask the chat assistant' is somewhat vague but indicates the tool is for asking questions. It doesn't explicitly distinguish from sibling 'create_chat', but context implies this is for existing 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 guidance on when to use this tool versus siblings. For example, it doesn't say to use this for ongoing conversations and 'create_chat' for new ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_chat创建聊天B
创建一个新的聊天助手,基于指定的数据集
| Name | Required | Description | Default |
|---|---|---|---|
| dataset_id | Yes | 数据集ID | |
| name | No | 聊天助手的名称,可选,默认为'RAGFlow助手' |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states 'create' without disclosing side effects, permissions requirements, error behavior, or whether the operation is reversible.
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-loaded with the core action. It is concise but could be slightly more structured or informative without adding length.
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 low complexity (2 params, no output schema), the description provides the basic purpose. However, it lacks usage context and behavioral details, making it only minimally complete.
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 clear descriptions for both parameters. The description adds no new meaning beyond the schema, which already defines dataset_id (required) and name (optional with default).
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 (create) and resource (chat assistant) with a specific basis (dataset). It distinguishes from siblings 'chat' and 'list_datasets' by implying creation vs. usage or listing.
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 vs. alternatives (e.g., 'chat' might be for interacting). No mention of prerequisites (e.g., dataset must exist) 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.
list_datasets列出数据集B
列出 RAGFlow 中的所有数据集
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, authentication requirements, or pagination behavior, which are important for a tool with no output schema.
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, appropriately sized for the simplicity of the operation.
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 description does not detail the output format or behavior (e.g., ordering, empty results), which is needed given the absence of an output schema.
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 tool has no parameters, and schema coverage is 100%. The baseline for zero parameters is 4, and no additional parameter semantics are needed.
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 'List all datasets in RAGFlow' using a specific verb and resource, distinguishing it from sibling tools like chat and create_chat.
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, nor any exclusions or prerequisites.
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. Dates show when Glama detected each change.
3 tool updates
v0.1.0- First observed
chat - First observed
create_chat - First observed
list_datasets
TDQS
Each tool has a clearly distinct purpose: chat queries an assistant, create_chat creates a new assistant, and list_datasets retrieves available datasets. No overlap in functionality.
All tool names follow a consistent snake_case verb_noun pattern (chat, create_chat, list_datasets), making them predictable and easy to understand.
With only 3 tools, the server is minimal. While this might suffice for basic interactions, it feels thin for a full RAGFlow integration.
The tool set covers only basic operations: chatting, creating a chat assistant, and listing datasets. Missing crucial CRUD operations for datasets and assistants, leaving significant gaps for agents.
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
Connects AI assistants to CloudQuell multi-cloud and AI cost, savings, anomaly, and budget data.
Access the GitHub API, enabling file operations, repository management, search functionality, and…
- mcpOAuthcom.keboola
Connect your AI assistants to Keboola and expose your data, transformations, SQL queries, ...
Manage SiteGPT chatbots and account resources through the SiteGPT API v2.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables LLMs to interact with Dify AI's chat completion API, including conversation context support and a restaurant recommendation tool.11MIT
- FlicenseBqualityDmaintenanceEnables interaction with the RAGFlow API to manage knowledge base datasets and conduct AI-driven chat sessions. Users can list datasets, create chat assistants, and retrieve or query information from specialized knowledge bases.4-
- FlicenseNot gradedqualityDmaintenanceEnables programmatic management of a Dify instance, including datasets, apps, and tools.-
- AlicenseBqualityBmaintenanceEnables AI assistants to manage contacts, send messages, handle conversations, and manage workspace via the Respond.io API.28106MIT
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/wang-junjian/ragflow-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server