Skip to main content
Glama
wang-junjian

RAGFlow MCP Server

by wang-junjian

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.md

Components

Tools

  1. list_datasets

    • 列出所有数据集

    • 返回数据集的 ID 和名称

  2. create_chat

    • 创建一个新的聊天助手

    • 输入:

      • name: 聊天助手的名称

      • dataset_id: 数据集的 ID

    • 返回创建的聊天助手的 ID、名称和会话 ID

  3. 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:8060

Claude 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:

  1. Sync dependencies and update lockfile:

uv sync
  1. Build package distributions:

uv build

This will create source and wheel distributions in the dist/ directory.

  1. Publish to PyPI:

uv publish

Note: You'll need to set PyPI credentials via environment variables or command flags:

  • Token: --token or UV_PUBLISH_TOKEN

  • Or username/password: --username/UV_PUBLISH_USERNAME and --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:8060

Upon launching, the Inspector will display a URL that you can access in your browser to begin debugging.

Available Tools

3 tools
chat聊天C

向聊天助手提问

ParametersJSON Schema
NameRequiredDescriptionDefault
session_idYes聊天会话ID
questionYes提问的问题

TDQS

C2.5/5.0
Behavior2/5

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.

Conciseness3/5

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.

Completeness2/5

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.

Parameters3/5

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.

Purpose3/5

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.

Usage Guidelines2/5

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

创建一个新的聊天助手,基于指定的数据集

ParametersJSON Schema
NameRequiredDescriptionDefault
dataset_idYes数据集ID
nameNo聊天助手的名称,可选,默认为'RAGFlow助手'

TDQS

B3.2/5.0
Behavior2/5

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.

Conciseness4/5

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.

Completeness3/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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 中的所有数据集

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.4/5.0
Behavior2/5

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.

Conciseness5/5

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.

Completeness2/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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.

  1. 3 tool updatesv0.1.0
    • First observedchat
    • First observedcreate_chat
    • First observedlist_datasets

TDQS

B3.1/5.0
Disambiguation5/5

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.

Naming Consistency5/5

All tool names follow a consistent snake_case verb_noun pattern (chat, create_chat, list_datasets), making them predictable and easy to understand.

Tool Count3/5

With only 3 tools, the server is minimal. While this might suffice for basic interactions, it feels thin for a full RAGFlow integration.

Completeness2/5

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

ActivityInactive
ResponsivenessNo issues

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

Related MCP Servers

Latest Blog Posts

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