Skip to content

Conversation

bneil
Copy link
Contributor

@bneil bneil commented Jul 4, 2025

Alright, so this is me biting off more than I can chew. I'm still testing out fixing #89 but wanted to get this up for feedback.

Big changes here are as follows:

  1. Adding transport_type and config - Was on the fence of just adding them into metadata but decided to make them proper columns. Now MCP servers can be either stdio (the old way) or
    HTTP.
  2. http.rs - I "think" this will work to hook into the streamable MCP servers (still testing). It's got session management, SSE streaming, the whole nine yards. Follows the MCP
    protocol but over HTTP instead of pipes.
  3. UI updates - Had to update the MCP server component to handle both transport types. You can now configure HTTP servers with URLs, auth, headers, etc.
  4. Database migration - Added the new columns with defaults so existing servers don't break.
  5. Deep link additions - Enhanced the tome:// URL handling to support HTTP servers too.

🚧 Still testing - The HTTP stuff compiles and looks right but I haven't actually tested it with a real streamable MCP server yet. The stdio path should still work fine though.

@mnoble
Copy link
Contributor

mnoble commented Jul 17, 2025

This is awesome. I need to sit down and review it more in depth, but I'll hold off on that until you've tested is a bit more. Some random thoughts/questions from a quick glance so far:

Adding transport_type and config - Was on the fence of just adding them into metadata but decided to make them proper columns. Now MCP servers can be either stdio (the old way) or HTTP.

I intended for metadata to be data from the server, so I agree, it makes sense for transport to be an explicit property/column.

http.rs - I "think" this will work to hook into the streamable MCP servers (still testing). It's got session management, SSE streaming, the whole nine yards. Follows the MCP protocol but over HTTP instead of pipes.

Is there anything you noticed that would prevent us from using StreamableHttpClientTransport, and kin, from the rmcp lib? Naively, it seems like we could cut down on a lot of those code in this PR by relying on that. I haven't worked with any of it yet, so this is purely just a question.

rmcp streamable example: https://github.com/modelcontextprotocol/rust-sdk/blob/main/examples/clients/src/streamable_http.rs

I'm going to be offline the next couple weeks, but I'll keep an eye for updates from when you've tested it a bit more 🙌

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants