Add functionality for MCP versions 2025-06-18 and 2025-11-25

[DePasqualeOrg]

I've implemented almost all the missing functionality in the Swift SDK, bringing it up to date with the latest protocol version. I also fixed several bugs that were noted in issues and PRs and many others that I found, and added tests for existing and new functionality. In some ways, the Swift SDK is now even more spec-compliant than the TypeScript and Python SDKs.

Over the course of five days, I used Opus 4.5 in Claude Code in a highly structured way to plan, generate, and verify the new functionality and tests based on the MCP spec and the TypeScript and Python SDKs. This included many rounds of verifications and corrections for each component.

I've found that this can work well with porting projects like this, where we have a clear spec and several mature SDKs in other languages, but review and real-world testing are still needed. I'm happy to keep improving anything that still needs work.

New in this PR

HTTP server support

• HTTPServerTransport: Streamable HTTP (2025-03-26+)
• The deprecated SSE server transport is not included, since streamable HTTP is now widely adopted.
• SessionManager: Manages multiple client sessions
• InMemoryEventStore: Event storage for session resumability
• Examples for Hummingbird and Vapor

Protocol 2025-06-18 features

• Elicitation (form mode): Servers can request structured input from users via form schemas
• Structured tool output: structuredContent and outputSchema on tools
• Resource links: ResourceLink content type in tool results
• Title fields: title on Tools, Prompts, Resources, ResourceTemplates
• Completions: Autocomplete suggestions for tool, prompt, and resource arguments

Protocol 2025-11-25 features

• Tasks (experimental): Long-running operations with polling model
• URL mode elicitation: Out-of-band flows for OAuth/credentials via external URLs
• Icons: icons metadata on tools, resources, prompts, templates, implementations
• Sampling tools: tools and toolChoice parameters in sampling requests
• Tool execution metadata: taskSupport field for controlling task behavior
• Enhanced enum schemas: Titled enums, multi-select, default values in elicitation
• Tool name validation: Warns on invalid tool names per spec guidance

Core features (previously missing)

• Progress notifications: Servers can report progress on long-running operations
• Roots: Clients can expose root directory URIs to servers
• MCP Protocol Logging: Servers can send log messages to clients

PRs superseded by this PR

• #170: Fix stream consumption in receive loop
  • See my comment for details
• #171: Fix client receive loop spinning after transport closes
  • See my comment for details
• #167: Support 2025-06-18 spec
  • See my comment for details
• #168: Support progress notifications
  • See my comment for details
• #118: Small change: append handlers in situ
  • Cherry-picked for attribution, but should be merged separately before this PR, after which I'll rebase this branch

Issues resolved by this PR

• #165: HTTP transport for servers

• #142: Elicitation support

• #139: ResourceLink in CallToolResult

• #137: NetworkTransport crash on reconnect

  • See my comment for details

• #134: Update to latest spec version

• #117: Tool.outputSchema and CallToolResult.structuredContent

• #110: Streamable server support

• #83: Completions support

• #82: Progress tracking support

Remaining work for this PR

• Merge PR #118 and rebase
• Create docs for new functionality
• Split docs into separate files
• Suggestion: add automated formatting for smoother collaboration
  • Add .git-blame-ignore-revs with formatting commit hash

Future work

• Schema validation for tool inputs and outputs, elicitation response
  • Use ajevans99/swift-json-schema?
• Add more convenience APIs like in TypeScript and Python SDKs
• OAuth support

[lin72h]

Finally! Thanks for keeping the Swift community up to date with the rest of the SDK.

[DePasqualeOrg]

Note that about 2/3 of the total line count of this PR is tests.

I've had some discussions with people on the MCP Contributors Discord about the sheer size of this PR, and I understand the challenge of reviewing it in one go. If we decide to move ahead with it, I think we can split this up and do a phased review and release.

Phase	Description	Lines	Files
1	Modified existing functionality	~3,100 net	17
2	Streamable HTTP server	~1,920	3
3	2025-03-26 missing features	~650	6
4	2025-06-18 features	~1,450	3
5	2025-11-25 (non-Tasks)	~700	6
6	Experimental Tasks	~4,200	10
	Subtotal (Source)	~12,000	45
	Refactored extensions*	~2,400	7
	Examples & docs	~1,400	7
	Total (excl. tests)	~15,800	59

I'd also like to encourage people to do the following:

• Sample a part of the codebase that you're already familiar with and tell me what you think.
• Try this PR for your use case and tell me if it works for you, and if not, what needs to be improved.
• Use your favorite agent to compare the before and after of individual parts of this PR and give an assessment.
• Use your favorite agent to compare individual parts of this PR to the spec and the TypeScript and Python SDKs and give an assessment.

I'd love to hear your feedback.

[DePasqualeOrg]

Since I mentioned issues in the existing codebase that I fixed over the course of my work on this PR, I've compiled lists of bug fixes, code quality improvements, and spec compliance fixes that I made, separate from new functionality that was added.

[stallent]

Thank you for taking the time to do this! This is really helpful explaining your rational. Haven't skimmed the bug fixes but did skim the "code quality improvements" doc. Many of them are great and solid improvements, but several are not necessarily obvious wins and will need some discussion. We can discuss them individually when the time comes but we might want to break them out into their own PR's eventually so the ones that are obvious improvements can be accepted quickly and the others can get either tweaked or removed. Great stuff! I appreciate you continuing to improve your PR

[DePasqualeOrg]

@stallent, I don't want to get bogged down in arguments over coding style. On most issues like this I'm willing to defer to the judgement of the best AI systems presented with the relevant information.

I'll continue development in DePasqualeOrg/mcp-swift-sdk. If anyone wants to help with review and testing, your feedback is very welcome.