rust-sdk

Summary Follow up on oxcabe's worker ownership review in #1186. This draft is based on #1186, so its diff contains only the refactor and its tests. Move http request cancellation, the control queue, and session generation into . Keep the ordinary queue and worker task in . Leave scheduling, retries, timeouts, cancellation behavior, and wire messages unchanged. Validation Passed locally: 21 client-only concurrency tests, including worker construction and conversion. 37 selected transport tests using the non-local features from . 13 http unit tests and six transport doctests. All-features suite: 506 unit tests, enabled integration tests, and 48 doctests passed (10 ignored), with the two exclusions below. Strict all-targets, all-features clippy with . Two unchanged downstream custom-adapter integration tests. Nightly formatting and diff checks. Two existing process tests remain excluded because the sandbox blocks process-state inspection: and . Neither test changed.

Summary Fail a streamable HTTP request POST when the server returns HTTP 200 with that is not a JSON-RPC message, instead of treating that body as Accepted and hanging . Problem maps any body that fails to parse as to . That fallback is correct for notification POSTs: nothing is waiting for a reply. The same branch also runs for requests. The worker then records the request id as pending and waits on the SSE/GET stream. never returns when the server answers + with , an empty body, or other non-JSON-RPC JSON. Public repro: 1. 2. 3. 4. Mock: initialize succeeds; returns + + Change Keep the Accepted fallback only when the outbound message is a notification, response, or error. For a request, return . The same check is applied in the reqwest client and the Unix socket client. Notification empty-200 handling from Ref #849 is unchanged. This does not implement the unexpected-content-type fallback in open Ref #1063. The parse-as-Accepted path was added in #687 (2026-02-26) for notification POSTs that lack an . Validation Red (production restored from , new tests only): Failed with and . Green (after the fix): same command, 5 passed in 0.01s. Also passed: Related Ref #849 (accept empty 200 for notification POSTs) Ref #1063 (notification POST response shape; still open). That PR tests that a request still rejects . It does not close JSON parse failure on a request POST.

Document rcm-rs (RCM) as an extension of RMCP that uses the LET imperative to expose polyglot package-management operations as MCP tools. Motivation and Context RCM is a polyglot package manager (Cargo, NPM, Composer/PPM, system packages) built around the LET imperative. It integrates the official RMCP SDK so AI agents can discover and invoke package-management, build, deploy, and workspace operations over the Model Context Protocol. Listing it under Extending makes the ecosystem more discoverable and shows a concrete example of using RMCP + LET together. How Has This Been Tested? Documentation-only change. Links to the RCM repository and crates.io page were verified. Breaking Changes None. This is a pure documentation update. Types of changes [ ] Bug fix (non-breaking change which fixes an issue) [ ] New feature (non-breaking change which adds functionality) [ ] Breaking change (fix or feature that would cause existing functionality to change) [x] Documentation update Checklist [x] I have read the MCP Documentation [x] My code follows the repository's style guidelines [x] New and existing tests pass locally [x] I have added appropriate error handling [x] I have added or updated documentation as needed Additional context Change is limited to the Related Projects → Extending section of the root README. Suggested entry: rcm-rs (crates.io) – Extends RMCP with the LET imperative: a polyglot package-manager surface (Cargo, NPM, Composer/PPM, system packages) exposed as MCP tools so AI agents can drive installs, builds, de​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​​