Add basic http client support

[jcat4]

Motivation and Context

Closes #3

Follow-up to https://github.com/modelcontextprotocol/ruby-sdk/pull/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 https://github.com/modelcontextprotocol/ruby-sdk/pull/27

Types of changes

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [x] Documentation update

Checklist

• [x] I have read the MCP Documentation
• [x] My code follows the repository's style guidelines
• [x] New and existing tests pass locally
• [x] I have added appropriate error handling
• [x] I have added or updated documentation as needed

Additional context

[jcat4]

Decided to build in auth, going to draft to test it

[jcat4]

Auth is tested and working

[topherbullock]

@jcat4 can you rebase on main and resolve conflicts? seems to be largely the model_context_protocol => mcp rename

[vickyonit]

Thank you for your work on this, @jcat4. We're looking forward to seeing it merged. Is there an expected timeline for this?

[jcat4]

@jcat4 can you rebase on main and resolve conflicts? seems to be largely the model_context_protocol => mcp rename

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!

[atesgoral]

@jcat4 @topherbullock Now that #27 is in, could we revisit this and get a client in there? 🙏

[jcat4]

@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]

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

[jcat4]

I've tested the new code in one of our local apps, and it's working as expected.

[jcat4]

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

[atesgoral]

@jcat4 Thanks for doing this!

[topherbullock]

@jcat4 can you fix up the suggestions and squash your commits pls? Thanks for pushing this through!

[koic]

Thank you for the client implementation. I've left some minor feedback. Since it doesn’t seem to be squashed yet, please squash your commits into one at the end.

[jcat4]

Since this is a user-specific setting, I think it should be defined in the developer's ~/.gitignore rather than in the repository.

@koic My view: if we never want a file committed, the repo should enforce it so we don’t rely on each contributor’s local setup. Is there a strong reason to prefer user-level ignores here?

[koic]

Because these are specific to the user's development environment (such as OS or editor) and not specific to the Ruby SDK. For more details, please refer to the discussion in the following closed PRs: https://github.com/rails/rails/pulls?q=is%3Apr+.DS_Store+is%3Aclosed+

[jcat4]

Because these are specific to the user's development environment (such as OS or editor) and not specific to the Ruby SDK. For more details, please refer to the discussion in the following closed PRs: https://github.com/rails/rails/pulls?q=is%3Apr+.DS_Store+is%3Aclosed+

Thanks for this! Hmmm... I do see that's how rails operates. If this is commonly how other open source ruby repos operate, I can make this change to be more inline.

But I do wanna say, I still personally disagree, as I think this change could avoid friction. Those 14 PRs in rails where this convo had to happen are examples of friction that could be avoided.

If you have any docs or anything on hand, would love to know more about why we want to have a platform-agnostic .gitignore!

[koic]

I'm personally convinced by the reasoning in the Rails repository, so I don't have any additional documentation beyond that. In any case, this doesn't seem to be the main focus of this PR. This point can serve as a starting place for the PR itself. I do have a bit of feedback, so I'll leave some additional comments.

[jcat4]

I had merge conflicts, had to rebase, resolve, and squash. Nothing of substance changed since last approval

EDIT: nvm, this part of the README changed, and found some stale YARD docs in the client

[koic]

This MCP client implementation can serve as a starting point and be improved as needed. In any case, no further conflicts should arise with this PR. Thank you for working on it!