Skip to content

Latest commit

 

History

History

mcp-client-ruby

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 
 
 
 
 
 
 
 
 

README.md

An LLM-Powered Chatbot MCP Client written in Ruby

An interactive chatbot MCP client: it launches an MCP server over stdio, lists its tools, and hands them to Claude, which can call them while answering your questions.

This example accompanies the Build an MCP client tutorial.

Prerequisites

Setup

Install the gems, then put your API key in a .env file (or export ANTHROPIC_API_KEY in your shell):

bundle install
cp .env.example .env
# then edit .env and add your key

Run the client

Pass the path to a server script. .rb servers are launched with ruby, .py with python3, and .js with node:

bundle exec ruby client.rb ../weather-server-ruby/weather.rb

Type a question (for example, "What's the weather in Sacramento?") and Claude answers using the server's tools. The client keeps the conversation for the whole session, so a follow-up such as "And the alerts for that state?" works. Type clear to start a new conversation, or quit to exit.

Without an ANTHROPIC_API_KEY, the client still connects, prints the server's tools, and exits — useful for verifying the MCP wiring without credentials.

Structured content

The spec says clients SHOULD validate structured results against the schema the tool declares, and this SDK's client does not do it for you — MCP::Client::Tool#output_schema hands back the raw schema from the wire and nothing checks results against it. So the client compiles each declared schema once at connect time with MCP::Tool::OutputSchema.new and validates every non-error result.

The two channels go to different readers: content is forwarded to the model, while structured_content is used as data — when a tool returns an array, the client counts its items rather than re-reading the prose. See Structured Content.

Before a tool result goes to the model, the client converts it to the Messages API's block types. Text stays text, a PNG, JPEG, GIF or WebP image becomes an image block, and a text resource becomes its text. Anything else, such as audio, becomes a placeholder like [unsupported result type: audio], so the model knows something was there. Empty text is dropped, because the Messages API rejects empty text blocks. A result with structured content and no text is sent as its JSON. A call the server rejects goes back to the model as a failed tool result, so it can correct itself, rather than ending the query.

Every request sends the same short system prompt. When a reply stops early, the client says so: [Reply cut off at the max_tokens limit] when it ran out of tokens, and [The model declined to answer; the query is not kept in history] when the model refused. A reply that was cut off, refused, empty or stopped at the tool-turn limit is not added to the history, and a query that fails with an error is dropped from it, so the next request stays valid.

MCP::Client::Stdio offers 2026-07-28 by default, so no negotiation setup is needed here.