Document That Tool Arguments Arrive with Symbol Keys

## Motivation and Context

The transports parse incoming JSON with `symbolize_names: true`, so a tool receives every key,
at every nesting level, as a Ruby symbol. The dispatch in `call_tool_with_args` only runs
a shallow `transform_keys(&:to_sym)`, which is effectively a no-op given the deep parse upstream.
Nothing in the SDK exercised that delivered shape: the README and examples take flat or primitive arguments,
and the tool tests invoke `call` with Ruby keyword arguments, so none go through the JSON parse to dispatch path.
A tool that reads a nested object with string keys (`payload["subject"]`) therefore passes its tests and then
returns nil against a real client.

Ruby keyword arguments bind only on symbol keys, so the top-level keys must be symbols for
the ergonomic `def call(message:, ...)` API to work. Aligning fully with the JSON wire shape that the spec and
the Python and TypeScript SDKs use (string keys) is not possible without a breaking change to that API.
This change therefore documents the existing contract rather than altering behavior.

Closes #412

## How Has This Been Tested?

New regression tests in `test/mcp/server_test.rb`:

- `tools/call` through the full `handle_json` path delivers nested object arguments with symbol keys at every level,
  and string-key access on a nested value returns nil.
- A tool called under the JSON-round-tripped argument shape receives symbol keys, mirroring what a transport hands it at runtime.

## Breaking Changes

None. This is a documentation and test change with no behavior change.
The `lib/mcp/server.rb` edit is a clarifying comment on the existing key handling.

## Additional context

Making nested objects tolerant of both string and symbol keys (indifferent access) is a possible future improvement
that would remove the footgun and move closer to the other SDKs. It is intentionally left out of scope here and
can be designed separately, since it is a behavior and dependency decision rather than a documentation fix.

docs/building-servers.md

@@ -180,6 +180,53 @@ server.define_tool(
 end
 ```
 
+### Tool argument keys
+
+Tool arguments are delivered as a `Hash` whose keys are Ruby symbols at every nesting level, including nested objects
+and objects inside arrays. The transports parse incoming JSON with `JSON.parse(..., symbolize_names: true)`,
+so by the time a tool runs, a wire payload such as `{"payload": {"subject": "greet"}}` arrives as `{ payload: { subject: "greet" } }`.
+
+This means top-level values are bound through keyword arguments (`def call(message:, payload: nil, server_context:)`),
+and nested objects must be read with symbol keys:
+
+```ruby
+class ExampleTool < MCP::Tool
+  description "Echoes a nested argument"
+  input_schema(
+    properties: {
+      message: { type: "string" },
+      payload: {
+        type: "object",
+        properties: {
+          subject: { type: "string" },
+        }
+      }
+    },
+    required: ["message"]
+  )
+
+  def self.call(message:, payload: nil, server_context:)
+    subject = payload && payload[:subject] # symbol key, not payload["subject"]
+    MCP::Tool::Response.new([{
+      type: "text",
+      text: "Message: #{message}; subject: #{subject}"
+    }])
+  end
+end
+```
+
+Reading a nested value with a string key (`payload["subject"]`) returns `nil`. This is a Ruby-specific contract:
+Top-level keyword arguments require symbol keys, and parsing JSON with `symbolize_names: true` symbolizes nested objects too.
+
+Calling a tool directly in a test with `MyTool.call(payload: { "subject" => "greet" }, server_context: nil)` passes string keys
+that a transport never delivers, so string-key access can pass tests yet fail against a real client.
+Exercise a tool under the delivered shape by round-tripping the arguments through JSON the same way a transport does:
+
+```ruby
+delivered = JSON.parse(JSON.generate(arguments), symbolize_names: true)
+MyTool.call(**delivered, server_context: nil)
+```
+
 ## Prompts
 
 Prompts are templates for LLM interactions. Like tools, they can be defined in three ways: