[Doc] Explain when the HTTP client needs event_stream_parser
## Motivation and Context The Installation page names faraday as the example of an optional dependency but leaves out event_stream_parser, which the HTTP client transport needs as soon as a server answers with SSE. The Transports page documents both gems, so a reader who starts from Installation learns about the second one only when a streaming response fails to parse. The Transports page also marks event_stream_parser as "optional, required only for SSE responses", which reads as a corner case. Whether a response is JSON or SSE is the server's choice, made for each response, a client must accept both, and this SDK's own server picks SSE by default and always on the modern lifecycle, so a client written for arbitrary servers needs both gems. Both pages now say so, and the Transports page spells out the one setup that can leave the gem out: a server known to answer with JSON alone, such as this SDK's server in JSON response mode serving handshake-lifecycle clients, and no listening stream. The Installation page shows the faraday-only Gemfile first and then the one that adds event_stream_parser, so both cases are visible at a glance. ## How Has This Been Tested? Documentation only; the Gemfile snippets on both pages match. ## Breaking Changes None.
This commit is contained in:
parent
8a24e50d1b
commit
0da0291887
2 changed files with 19 additions and 2 deletions
|
|
@ -64,7 +64,14 @@ The stdio transport automatically handles:
|
|||
|
||||
Use the `MCP::Client::HTTP` transport to interact with MCP servers using simple HTTP requests.
|
||||
|
||||
You'll need to add `faraday` as a dependency in order to use the HTTP transport layer. Add `event_stream_parser` as well if the server uses SSE (`text/event-stream`) responses:
|
||||
You'll need to add `faraday` as a dependency in order to use the HTTP transport layer, and `event_stream_parser`
|
||||
to read SSE (`text/event-stream`) responses.
|
||||
Whether a response is JSON or SSE is the server's choice, made for each response, and a client must accept both,
|
||||
so a client written for arbitrary servers needs both gems. This SDK's own server picks SSE by default and always
|
||||
does on the modern lifecycle, and the listening stream that `on_elicitation` and `on_sampling` open is SSE as well.
|
||||
`event_stream_parser` is loaded on the first SSE response, so it can be left out only against a server known to
|
||||
answer with JSON alone, such as this SDK's server in [JSON response mode](/server/transports/#json-response-mode)
|
||||
serving handshake-lifecycle clients, and only while no listening stream is opened:
|
||||
|
||||
```ruby
|
||||
gem "mcp"
|
||||
|
|
|
|||
|
|
@ -38,6 +38,16 @@ $ gem install mcp
|
|||
You may need to add additional dependencies depending on which features you wish to access. For example, the HTTP client transport requires the `faraday` gem:
|
||||
|
||||
```ruby
|
||||
gem "mcp"
|
||||
gem "faraday", ">= 2.0"
|
||||
```
|
||||
|
||||
Reading SSE (`text/event-stream`) responses needs `event_stream_parser` as well.
|
||||
Whether a response is JSON or SSE is the server's choice, made for each response, and this SDK's own server picks SSE by default,
|
||||
so a client written for arbitrary servers needs both gems:
|
||||
|
||||
```ruby
|
||||
gem "faraday", ">= 2.0"
|
||||
gem "event_stream_parser", ">= 1.0"
|
||||
```
|
||||
|
||||
The [Transports](/client/transports/#http-transport-layer) page describes the one setup where `faraday` alone is enough.
|
||||
|
|
|
|||
Loading…
Reference in a new issue