typescript-sdk

According to SEP-2133, the protocol supports extensions which be be advertised in the capabilities object. This PR adds this field to the SDK Motivation and Context This enables extensions to build upon the typescript-sdk How Has This Been Tested? Existing and new tests pass. Breaking Changes No Types of changes [ ] Bug fix (non-breaking change which fixes an issue) [X] New feature (non-breaking change which adds functionality) [ ] Breaking change (fix or feature that would cause existing functionality to change) [ ] 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 [ ] I have added or updated documentation as needed Additional context

Refactor RegisteredTool, RegisteredPrompt, RegisteredResource to proper classes Motivation and Context The , , , and types were previously plain object types. This refactoring converts them to proper classes with: Private fields using syntax for encapsulation Getter methods for read-only access to properties Simplified method using for protocol fields Constructor callbacks pattern for communicating with New getter methods on to retrieve all registered items Added support to (for parity with protocol type) How Has This Been Tested? passes passes 487 tests passing Breaking Changes Yes, users will need to update their code: Note: In v1, the method used which did not match the field used in . This inconsistency has been fixed in v2 — both now use . New getter methods on : → → → → Types of changes [ ] Bug fix (non-breaking change which fixes an issue) [x] New feature (non-breaking change which adds functionality) [x] 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 New file structure Key design decisions 1. Private fields with : Uses JavaScript private class fields for true encapsulation 2. Protocol fields grouped: Protocol-derived fields stored in object, SDK-specific fields stored separately 3. Simplified update(): Uses so new protocol fields automatically work 4. Constructor callbacks: Classes receive , , callbacks for communicating state changes to 5. Type derivation with Omit**: Config types derived from protocol types using to automatically include new fields

Add integration tests that run MCP server/client round-trips natively on Bun and Deno using their respective test runners, verifying the SDK works across runtimes beyond Node.js. Add bun.test.ts using bun:test + Bun.serve() Add deno.test.ts using Deno.test + Deno.serve() + node:assert Add test-runtimes CI job (Bun 1.x + Deno v2.x matrix) Gate publish job on test-runtimes passing Exclude runtime-specific tests from vitest and tsconfig Motivation and Context How Has This Been Tested? Breaking Changes Types of changes [ ] Bug fix (non-breaking change which fixes an issue) [x] 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