feat: add swift-sdk to the built-in SDK matrix - #432
Open
shoemoney wants to merge 1 commit into
Open
Conversation
Registers modelcontextprotocol/swift-sdk, whose conformance fixtures already
exist upstream (Sources/MCPConformance/{Client,Server}, exposed as the
mcp-everything-client and mcp-everything-server products) but had no entry here.
SwiftPM writes binaries to a per-triple directory and maintains a .build/debug
symlink to it, so the fixture paths stay portable across host architectures.
The server defaults to port 3001; --port pins it to the 3000 convention the
other entries use.
Verified locally on macOS 26 / arm64 with Swift 6.2.4:
client --suite core 216 passed, 0 failed (baseline check passed)
server 67 passed, 2 failed
Also swaps the 'unknown SDK' fixture in the tests from swift-sdk to kotlin-sdk,
since swift-sdk is no longer unknown.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
KNOWN_SDKScovers seven SDKs but notswift-sdk, even though its conformance fixtures already exist upstream —Sources/MCPConformance/{Client,Server}, exposed as themcp-everything-clientandmcp-everything-serverproducts and driven byscripts/run-conformance.sh. This registers it.Two details worth calling out:
.build/arm64-apple-macosx/debug) but also maintains a.build/debugsymlink to it, so./.build/debug/mcp-everything-clientstays portable across host architectures.--port 3000pins it to the convention the other entries use.I also swapped the "unknown SDK" fixture in the tests from
swift-sdktokotlin-sdk, sinceswift-sdkis no longer unknown.Verified locally on macOS 26 / arm64, Swift 6.2.4, using the config's own build command (no
--skip-build):One thing I want to flag rather than paper over.
swift-sdk's checked-inconformance-baseline.ymlis currently justclient: [], and its own script runs the client with--suite core. Against the wider default suite the client surfaces 22 failures that aren't in that baseline — auth (DPoP, WIF,isshandling, offline-access), HTTP header scenarios, and two JSON-Schema scenarios. Those look like genuinely unimplemented features rather than harness problems, so I did not try to hide them behind a broadened baseline. Happy to either land this as-is and let the matrix show the real state, or hold it until a baseline update lands upstream — your call on which you prefer.Of the two server failures,
resources-listis a real spec bug in the fixture rather than a harness issue: the everything-server returns the resource templatetest://template/{id}fromresources/list, where templates belong inresources/templates/list, and{id}fails the spec'sformat: "uri"check. I've opened a separate PR againstswift-sdkfor it: modelcontextprotocol/swift-sdk#269. The remaining failure iselicitation-sep1330-enums.