[Bug]: MCP server tools/list crashes with "'str' object has no attribute 'get'" — list_chats() mishandles the /chats response shape

[hen1289]

Self Checks

• I have searched for existing issues search for existing issues, including closed ones.
• I confirm that I am using English to submit this report (Language Policy).
• Non-english title submitions will be closed directly ( 非英文标题的提交将会被直接关闭 ) (Language Policy).
• Please do not modify this template :) and fill in all the required fields.

RAGFlow workspace code commit ID

32c5cb1

RAGFlow image version

v0.26.3

Other environment information

- RAGFlow version: **v0.26.3**
- ragflow-mcp-server: **1.19.0** (from `serverInfo` on `initialize`)
- Deployment: Docker, `--enable-mcpserver --mcp-mode=host`, doc engine = elasticsearch

Actual behavior

Describe the bug

The MCP server crashes on every tools/list call, so no MCP client can load any tools. initialize succeeds, but tools/list returns:

MCP error 0: 'str' object has no attribute 'get'

Server log:

ERROR:mcp.server.streamable_http:Error in message router
...
AttributeError: 'str' object has no attribute 'get'

Root cause

list_tools() in mcp/server/server.py builds its tool descriptions by calling both list_datasets() and list_chats():

@app.list_tools()
async def list_tools(*, connector, api_key):
    dataset_description = await connector.list_datasets(api_key=api_key)
    chat_description = await connector.list_chats(api_key=api_key)   # <-- crashes

list_chats() iterates the REST response's data as if it were a list of chat dicts:

chat_count = len(res_json.get("data", []))
for data in res_json.get("data", []):
    d = {"id": data.get("id"), "name": data.get("name"), "description": data.get("description", "")}

But GET /api/v1/chats returns data as an object, not a list:

{"code": 0, "data": {"chats": [], "total": 0}, "message": "success"}

So the loop iterates the dict's keys ("chats", "total" — strings) and data.get("id") raises 'str' object has no attribute 'get'. Since list_tools() always calls list_chats(), tools/list fails entirely and the MCP server is unusable (host and self-host modes). list_datasets() is unaffected because GET /api/v1/datasets returns data as a list.

Expected behavior

No response

Steps to reproduce

1. Run RAGFlow v0.26.3 with the MCP server enabled (`--enable-mcpserver --mcp-mode=host`).
2. Connect any MCP client (e.g. Claude Code) and request `tools/list`.
3. `initialize` succeeds; `tools/list` fails with the error above.

Additional information

Proposed fix

In list_chats(), read chats from data["chats"]:

chats = res_json.get("data", {}).get("chats", [])
chat_count = len(chats)
for data in chats:
    d = {"id": data.get("id"), "name": data.get("name"), "description": data.get("description", "")}

[dosubot]

Hi @hen1289! I'm Dosu and I'm helping the InfiniFlow team.

Your diagnosis is spot on. This is a duplicate of #16638 [1], and the fix has already been merged via PR #16639 [2].

The fix adds a type check in mcp/server/server.py to handle the dict envelope before iteration:

_chats_data = res_json.get("data", [])
if isinstance(_chats_data, dict):
    _chats_data = _chats_data.get("chats", [])

This is already in the codebase [2], so pulling the latest nightly image or waiting for the next release (post-v0.26.3) should resolve the issue for you.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[zeweihan]

Strong root-cause isolation — the data being {"chats": [], "total": 0} while the loop treats it as a list of chat dicts is unambiguous. Worth naming why this is a response-envelope contract defect, not just a .get() typo, and why the crash is actually the better of the two possible outcomes.

1. The real root cause is response-envelope inconsistency across endpoints, not the .get() call. GET /api/v1/datasets returns data as a list; GET /api/v1/chats returns data as an object with pagination keys ({"chats": [...], "total": N}). Code written against the first shape and applied to the second is fragile by construction — the .get() crash is the symptom, but any consumer that assumed a uniform envelope would fail the same way the moment RAGFlow adds a third endpoint with a third shape. The durable fix isn't isinstance(data, dict): data = data.get("chats", []) (the #16639 patch) — that's a correct patch, but it papers over the fact that the REST surface silently diverges on what data means. A typed response contract (every list endpoint returns {data: [...], total: N}, or every endpoint returns {data: {items: [...], total: N}}) would have made this bug impossible rather than merely caught at runtime. The list_datasets path being unaffected is the tell: the two siblings work by coincidence of shape, not by contract.

2. There's a silent-wrong-count sibling hiding one line above the crash. Look at chat_count = len(res_json.get("data", [])). When data is {"chats": [], "total": 0}, len() returns 2 (the number of dict keys), not 0. So even before the loop crashes, the count reported upstream is 2 for a corpus of 0 chats. This is the plausible-but-wrong shape, and it's the more dangerous failure mode: if a future "defensive" refactor wrapped the loop in try/except (a common instinct on a crash like this), the .get() would stop raising, chat_count would silently read 2, the tool description would be built over an empty chat set with an inflated count, and there would be no signal at all — no crash, no exception, just a wrong number baked into a tool description that an MCP client trusts. The loud crash is doing you a favor; it's the silent version that survives in production.

3. The blast radius is capability-routing, not just tool listing. list_tools() builds tool descriptions from the chat list, and an MCP client uses those descriptions to decide which tools it can call and how to route a user's request. A silent degradation here (empty/wrong chat list, inflated count) doesn't just mislabel a menu — it changes which capabilities the agent believes exist, and the agent routes a "summarize this conversation" request to a chat id that either doesn't resolve or resolves to the wrong session. For anyone wiring RAGFlow's MCP server into an agent that operates on privileged corpora (a compliance KB where "chat" sessions carry matter context), a tool-routing decision made on a silently-wrong chat inventory is exactly the class of failure where the agent looks like it succeeded — it called a tool, got a response — but the response came from the wrong conversation, with no signal. That's the plausible-but-wrong-at-routing-layer signature, and it's downstream of the same shape-confusion.

4. Companion, consistent with the rest of the connector/parsing campaign. A response-envelope assertion (assert isinstance(data, list) or "items" in data, or a pydantic model per endpoint) turns the shape assumption from implicit to load-bearing-and-checkable — so the next time an endpoint quietly returns a paginated envelope, the failure is a contract violation at the boundary, not a 'str' has no attribute 'get' three frames deep inside a tool-description builder. The isinstance normalization in #16639 is the right immediate fix; the durable fix is to stop having two response shapes for the same conceptual thing. Same family as the WebDAV silent-delete (#16636, where "failed to list" collapsed with "successfully listed zero") and the connector identity issues — the unifying defect is always a type/shape assumption that the upstream silently violated, and the durable remedy is always make the contract explicit so the violation surfaces at the boundary instead of deep in a consumer.

[wangq8]

should be dup of #16638 and fixed in PR #16639
try latest v0.26.4