feat: Add MCP 2025-11-25 example server and test client#91
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3c8fe47d22
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
lib/mcp_client/task.rb
Outdated
| progress: json['progress'] || json[:progress], | ||
| total: json['total'] || json[:total], | ||
| message: json['message'] || json[:message], | ||
| result: json['result'] || json[:result], |
There was a problem hiding this comment.
Preserve false task results when parsing JSON
Task.from_json reads result with json['result'] || json[:result], so a valid boolean false result is treated as missing and becomes nil. Tasks can return primitive JSON values, so this silently corrupts task outcomes (for example, a completed check that returned false) when clients parse server responses.
Useful? React with 👍 / 👎.
lib/mcp_client/task.rb
Outdated
| result['progress'] = @progress if @progress | ||
| result['total'] = @total if @total | ||
| result['message'] = @message if @message | ||
| result['result'] = @result if @result |
There was a problem hiding this comment.
Preserve false task results when serializing tasks
Task#to_h only includes 'result' when @result is truthy, which drops legitimate boolean false results from serialized task payloads. Any code that logs, caches, or forwards task state through to_h/to_json will lose the original result semantics and conflate false with "no result".
Useful? React with 👍 / 👎.
lib/mcp_client/client.rb
Outdated
| begin | ||
| result = srv.rpc_request('tasks/create', rpc_params) | ||
| MCPClient::Task.from_json(result, server: srv) | ||
| rescue MCPClient::Errors::ServerError, MCPClient::Errors::TransportError => e |
There was a problem hiding this comment.
Catch ConnectionError in task operations
create_task rescues ServerError/TransportError but not ConnectionError, even though rpc_request raises ConnectionError on auth/network failures. In those paths this method (and the same pattern in get_task/cancel_task) leaks a different exception type instead of the documented TaskError, making task failure handling inconsistent for callers.
Useful? React with 👍 / 👎.
70694b7 to
de79694
Compare
- examples/mcp_2025_11_25_server.py: Python FastMCP server demonstrating audio content, resource annotations, tool annotations, sampling, completion with context, ResourceLink, and tasks - examples/test_mcp_2025_11_25.rb: Ruby client testing all features with clear PASS/FAIL output
de79694 to
16304e2
Compare
create_task, get_task, and cancel_task now rescue ConnectionError alongside ServerError and TransportError, wrapping it as TaskError for consistent error handling.
Adds comprehensive examples demonstrating all new MCP 2025-11-25 features:
Python server (
examples/mcp_2025_11_25_server.py):Ruby test client (
examples/test_mcp_2025_11_25.rb):Note: This branch includes all 9 feature branches merged together. Merge the individual PRs (#81-#89) first, then rebase this.