[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:
Koichi ITO 2026-09-06 03:19:52 +09:00
commit 0da0291887
2 changed files with 19 additions and 2 deletions

View file

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

View file

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