galaxyproject / galaxyproject/loom
Galaxy MCP: tools return "Not connected" mid-session even though connect reports success (37 tools)
- Dominant language
- TypeScript
- Stars
- 14
- Forks
- 12
- Avg merge
- 6d 5h
- Merged PRs (30d)
- 17
Description
Reported via Orbit beta feedback (0.3.1, macOS, DeepSeek provider).
Mid-session, Galaxy MCP tool calls start failing with `Not connected` even though `mcp connect galaxy` immediately beforehand reports success and lists all 37 tools. The agent looped: `mcp(connect="galaxy")` -> "galaxy (37 tools)", then `galaxy_get_histories` / `galaxy_get_history_contents` / `galaxy_connect` -> `Failed to call tool: Not connected`, repeatedly. Also seen on `galaxy_download_dataset`: `MCP error -32001: Request timed out` and `MCP error -32000: Connection closed`.
So the MCP server's connection state is inconsistent: the server process is up (the tool list resolves) but the underlying Galaxy client session reports "Not connected" for actual calls, and reconnect attempts don't recover it within the session. Paraphrasing the model's own summary: "the Galaxy connection is unstable -- MCP shows connected but individual Galaxy tools return Not connected."
Possibly related to #72 (dead-socket tool failures / stale Galaxy state), but here it isn't tied to suspend/idle -- it's mid-session, connect-succeeds-but-calls-fail. Likely in the galaxy-mcp connection/session lifecycle (the `uvx galaxy-mcp` server) or how loom proxies the connection. Worth reproducing and checking whether a dropped connection leaves the tool registry intact while the bioblend session is dead (and why reconnect doesn't revive it).
Contributor guide
No contributing guide indexed for this repository
Research direction
Reproduce the failure with mcp(connect="galaxy") and the listed Galaxy tool calls, then inspect the galaxy-mcp connection/session lifecycle and how loom proxies it. Compare the tool registry state with the underlying bioblend session, including reconnect behavior. Done means the failure is fixed so calls recover after reconnect, or the stale state is reported consistently.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100