Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@rubyhash-mcp diff these two Ruby hashes from test output"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for RubyHash. Gives any MCP-capable agent (Claude Code, Claude Desktop, Cursor, and others) two deterministic Ruby tools:
ruby_hash_diff: compare two Ruby hash literals, or paste raw failing Minitest/RSpec output, and get a structured report of exactly what changed: changed values with before and after, added and removed keys, and explicit type changes (nil to String, Integer to Float, symbol keys vs string keys).
ruby_to_json: convert a Ruby hash or array literal (hashrockets, symbol keys, shorthand syntax, nesting, nil/true/false) to clean JSON with sorted keys.
Everything runs locally in the server process. Nothing is uploaded, logged, or stored, the same privacy promise as rubyhash.dev.
ruby_hash_diff: Compare two Ruby hash literals, or paste raw failing Minitest/RSpec output, and get a structured report: changed values with before and after, added and removed keys, and explicit type changes (nil to String, Integer to Float, symbol keys vs string keys).
ruby_to_json: Convert a Ruby hash or array literal (hashrockets, symbol keys, shorthand syntax, nesting, nil/true/false) to clean JSON with alphabetically sorted keys.
Related MCP server: JSON Compare MCP Server
When a Ruby test fails on two large nearly identical hashes, comparing them by reading is slow and error prone, for humans and for language models. A 40-key nested hash diff burns context and invites mistakes. This server does the comparison with a real recursive descent parser and hands back only the differences, deterministically.
{
"mcpServers": {
"rubyhash": {
"command": "npx",
"args": ["-y", "rubyhash-mcp"]
}
}
}Or for Claude Code:
claude mcp add rubyhash -- npx -y rubyhash-mcpInput (raw test output):
-{"uid"=>"u@example.test", "role"=>"admin", "seats"=>3}
+{"uid"=>"u@example.test", "role"=>"editor", "seats"=>3.0}Output:
{
"equal": false,
"summary": "2 changed, 0 added, 0 removed, 1 type change",
"changed": [
{ "path": "role", "before": "admin", "after": "editor", "typeChanged": false },
{ "path": "seats", "before": 3, "after": 3, "beforeType": "Integer", "afterType": "Float", "typeChanged": true }
]
}If you cannot run a local MCP server, the same tools are exposed at the RubyHash Agent API, with an OpenAPI description and an x402 machine-payable catalog.
npm install
npm test # 36 unit testsMIT for this package. The rubyhash.dev site and its browser tool are separate, private, and all rights reserved.
Compare two Ruby hash literals and return exactly what changed: changed values with before/after, added and removed keys, and explicit type changes (nil to String, Integer to Float, symbol vs string keys). Pass either expected and actual as Ruby hash strings, or pass raw failing Minitest/RSpec output in raw and the first two hash literals found will be compared. Much cheaper and more reliable than eyeballing large nested hashes in test output.
| Name | Required | Description | Default |
|---|---|---|---|
| raw | No | Raw failing test output containing two hash literals (lines may be prefixed with - and +) | |
| actual | No | Actual Ruby hash literal, e.g. {"role"=>"editor"} | |
| expected | No | Expected Ruby hash literal, e.g. {"role"=>"admin"} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool compares hashes and returns specific diff details, including type changes. Does not mention side effects, but tool is inherently read-only and non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundant information. Every part contributes to understanding the tool's function and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description lists return details (changed values, added/removed keys, type changes). Adequate for a 3-param tool with well-described behavior, though additional output format info could help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but description adds value by explaining how the 'raw' parameter extracts hash literals from test output, and that actual/expected are Ruby hash strings. This goes beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares two Ruby hash literals and returns changed values, added/removed keys, and type changes. Differentiates from sibling ruby_to_json by focusing on diffing rather than conversion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on using either raw test output or direct expected/actual hashes. Does not explicitly state when not to use or mention alternatives beyond the sibling tool name, but gives clear context for use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Parse a Ruby hash or array literal (hashrockets, symbol keys, shorthand syntax, nesting, nil/true/false) and return clean JSON with alphabetically sorted keys. Symbols are rendered as ":name" strings.
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | Ruby hash or array literal, e.g. {name: "x", "role" => :admin} | |
| sort_keys | No | Sort hash keys alphabetically (default true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses key behaviors: sorting keys and rendering symbols as ':name' strings. However, it does not address error handling for invalid Ruby input or whether the output is a JSON string (vs. object), leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. The description is front-loaded with the core action and includes relevant details about syntax and output formatting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two well-documented parameters and no output schema, the description provides adequate context for basic usage. However, it lacks information about error behavior and output format specifics, which would be needed for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description's value beyond the schema is limited. It adds a detail about symbol rendering but does not explain the effect of sort_keys beyond what the schema states. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: parsing a Ruby hash/array literal and returning clean JSON with sorted keys. It specifies supported syntax (hashrockets, symbol keys, shorthand, nesting, nil/true/false), making it distinct from the sibling tool ruby_hash_diff.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need Ruby-to-JSON conversion) but does not explicitly state when to use this tool versus alternatives like ruby_hash_diff. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0ruby_hash_diffruby_to_jsonThe two tools have clearly distinct purposes: one compares two Ruby hashes and returns a diff, the other converts a Ruby hash/array literal to JSON. There is no overlap or ambiguity.
Both tool names follow a consistent verb_noun snake_case pattern: ruby_hash_diff and ruby_to_json. The prefix 'ruby_' is shared, and the second part describes the action ('hash_diff' vs 'to_json').
With only 2 tools, the server is minimal but still focused. It feels slightly thin for a general utility server, but for a niche Ruby hash utility it is acceptable and not excessive.
The tools cover diffing and conversion, which are useful but there are obvious gaps such as merging, validation, or formatting. The surface is not severely incomplete but lacks typical CRUD lifecycle coverage.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Compare two JSON files deeply, ignoring order, to surface every difference. Get a clear, structure…
Compare two JSON files deeply, regardless of order. Get a detailed difference report highlighting…
Compare two JSON files deeply without worrying about key or array order. Detect missing, extra, an…
31 deterministic tools: JSON→Zod, regex, JWT, curl→fetch, hashing, encoding, UUIDs, encrypted links
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/builtbyproxy/rubyhash-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
