Add basic http client support #28
Conversation
|
Decided to build in auth, going to draft to test it |
|
Auth is tested and working |
|
@jcat4 can you rebase on main and resolve conflicts? seems to be largely the |
|
Thank you for your work on this, @jcat4. We're looking forward to seeing it merged. Is there an expected timeline for this? |
Sorry, lost track of this. I thought we wanted to go with the pluggable approach? If so, I can close this Or I can try to rework this to be closer to what y'all envisioned! |
|
@jcat4 @topherbullock Now that #27 is in, could we revisit this and get a client in there? 🙏 |
I'll make some time this week to knock this out |
jcat4
force-pushed
the
add-basic-http-client-support
branch
from
e72bcfa to
3a0b9b8
Compare
| @@ -216,7 +218,7 @@ $ ruby examples/stdio_server.rb | |||
| {"jsonrpc":"2.0","id":"2","method":"tools/list"} | |||
| ``` | |||
|
|
|||
| ## Configuration | |||
| ### Configuration | |||
There was a problem hiding this comment.
At the moment, this is server-specific. If we have this patch a client config too (or stop having the config scoped to just the server), we can move this somewhere else in the README
|
Unsure if we still feel strongly about going with a pluggable approach, and haven't had any feedback on that yet. Will put this as-is in for review But please let me know if we should go somewhere else with the interface! I want us to get as close to right as possible on our first release |
|
I've tested the new code in one of our local apps, and it's working as expected. |
|
Spoke with @juharris, and we decided a pluggable approach would probably be better. The primary reason is it will allow folks to implement and pass their own custom transport layers (and open the door for other gems to add more, too!). The first step might be a bit manual (create your transport, create your client by passing your transport, send messages to your client), but we can iterate later with convenience wrappers that won't break existing code Overall, it seems like the safer bet. What we have is functional, but maybe not flexible enough for a public gem. Will begin work on this again next week when I have time, I think I can knock something out relatively quickly |
| @@ -8,3 +8,6 @@ | |||
| /spec/reports/ | |||
| /tmp/ | |||
| Gemfile.lock | |||
|
|
|||
| # Mac stuff | |||
| .DS_Store | |||
|
@jcat4 Thanks for doing this! |
Motivation and Context
Closes #3
Follow-up to #27
Happy to close the other PR and just keep this one if we want.
This adds the ability to build MCP clients with the ruby sdk. I've started with a basic HTTP client. We can add other things (i.e. streamable HTTP) later.
For simplicity, I'm just allowing custom headers to specify auth. I didn't want to build an abstraction around different auth types prematurely.
How Has This Been Tested?
The local gem build has been tested in 2 different internal repositories and is working as expected so far.
Breaking Changes
Just the stuff from #27
Types of changes
Checklist
Additional context