Support 2025-06-18 Spec

[ajevans99]

Added/Changed

• Add support for structured tool output (PR #371)
• Add support for elicitation, enabling servers to request additional information from users during interactions. (PR #382) Requires server to client implementation, types only for now
• Add support for resource links in tool call results. (PR #603)
• Add _meta field to additional interface types (PR #710), and specify proper usage. Also adds extraFields to allow [key: string]: unknown; on __Result types align with interfaces/schema https://modelcontextprotocol.io/specification/2025-06-18/schema_
• Add title field for human-friendly display names, so that name can be used as a programmatic identifier (PR #663)

Not Handled

• Remove support for JSON-RPC batching (PR #416)
• Require negotiated protocol version to be specified via MCP-Protocol-Version header in subsequent requests when using HTTP (PR #548).
• Add context field to CompletionRequest, providing for completion requests to include previously-resolved variables (PR #598).

Motivation and Context

Support many changes in recent MCP spec update.
https://modelcontextprotocol.io/specification/2025-06-18/changelog

How Has This Been Tested?

• New unit tests
• MCP Inspector npx @modelcontextprotocol/inspector@latest

Breaking Changes

• New case on public enum Tool.Content.resourceLink
• Updated associated values on enum case Tool.Content.resource to include optional title and annoations properties

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)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

_meta is not a Swifty name but does map nicely to the spec. Open to suggestions

[alainakafkes]

hi there and thank you for taking a stab at supporting the latest MCP spec! i saw this PR because i am hoping to use Result's structuredOutput for a project. i have no special role in this repo but wanted to offer some feedback to help build interest in this work

[ajevans99]

hi there and thank you for taking a stab at supporting the latest MCP spec! i saw this PR because i am hoping to use Result's structuredOutput for a project. i have no special role in this repo but wanted to offer some feedback to help build interest in this work

Thanks for the early review. Implemented a bunch of your suggestions and re-thought the meta and general fields.

[aehlke]

I see you had some changes last week. Is this ready to use as a fork until it gets reviewed? I hope this will be merged if it is ready. Thanks!

[ajevans99]

I see you had some changes last week. Is this ready to use as a fork until it gets reviewed? I hope this will be merged if it is ready. Thanks!

Ready on my side. @mattt could we get a review when you get a chance

[movetz]

Hi folks! @ajevans99@aehlke@alainakafkes

Can we continue in the official Discord and swift-sdk-dev channel? You can find the link on the official site community section.

Actually, we (at @MacPaw) have made almost the same updates in our private fork and are planning the next changes for the latest version. It makes more sense to combine our work and move faster. And it will be great if we can discuss it 🙏.

[aehlke]

Just to note for those who find this here - on Discord the latest is that there will be an online meeting on Jan 9th where this project's maintenance status and stewardship may be discussed (by those here who are stepping up to raise the topic and make proposals)

[DePasqualeOrg]

Thanks for your contribution, @ajevans99. Since my PR #175, which I developed independently, overlaps with this one, I wanted to explain some of the differences between the two. If you think I've missed something, or if you have any feedback on my PR, please let me know.

My PR fully implements all the required _meta and extraFields support. I chose a simpler approach by omitting _meta key validation, which neither the TypeScript nor the Python SDK implements.

Comparison

Feature	Spec	PR #167	TS SDK	Python SDK	My PR #175
_meta on Result types	Required	✅	✅	✅	✅
_meta on RequestParams	Required	✅	✅	✅	✅
_meta on NotificationParams	Required	✅	✅	✅	✅
_meta on content types	Required	✅	✅	✅	✅
_meta on entity types	Required	✅	✅	✅	✅
extraFields on Results	Required	✅	✅	✅	✅
_meta key validation	Not in schema	✅	❌	❌	❌
title fields	Required	✅	✅	✅	✅
outputSchema on Tool	Required	✅	✅	✅	✅
ResourceLink	Required	✅	✅	✅	✅
Icons	2025-11-25	❌	✅	✅	✅
Tasks	2025-11-25	❌	✅	✅	✅
URL elicitation	2025-11-25	❌	✅	✅	✅
Full elicitation impl	Required	Types only	✅	✅	✅
Protocol version	—	2025-06-18	2025-11-25	2025-11-25	2025-11-25

Differences in my PR #175

No _meta key validation: This PR adds ~200 lines to validate _meta key formats. I omitted this because the JSON Schema uses additionalProperties: {} with no format constraints, and the Python and TypeScript SDKs don't validate keys.

ResultWithExtraFields protocol: I use a protocol with default implementations for consistent extraFields decoding across all Result types, which reduces code duplication.

RequestMeta type: Captures progressToken plus arbitrary additional fields, matching how the TypeScript and Python SDKs handle request metadata.

Flattened Task results: GetTask.Result and CancelTask.Result flatten Task fields per the spec's allOf[Result, Task], matching TS (Result & Task) and Python (class GetTaskResult(Result, Task)).

2025-11-25 support: I support the latest protocol version, including Tasks, Icons, and URL elicitation.

[movetz]

@ajevans99 Big thx! You covered many things, and the changes are aligned with the current architecture. We decided to merge it and reuse it for the next changes. We open for any help and contributions and will mention you in the official Discord channel.

[ajevans99]

Added/Changed

• Add support for structured tool output (PR #371)
• Add support for elicitation, enabling servers to request additional information from users during interactions. (PR #382) Requires server to client implementation, types only for now
• Add support for resource links in tool call results. (PR #603)
• Add _meta field to additional interface types (PR #710), and specify proper usage. Also adds extraFields to allow [key: string]: unknown; on __Result types align with interfaces/schema https://modelcontextprotocol.io/specification/2025-06-18/schema_
• Add title field for human-friendly display names, so that name can be used as a programmatic identifier (PR #663)

Not Handled

• Remove support for JSON-RPC batching (PR #416)
• Require negotiated protocol version to be specified via MCP-Protocol-Version header in subsequent requests when using HTTP (PR #548).
• Add context field to CompletionRequest, providing for completion requests to include previously-resolved variables (PR #598).

Motivation and Context

Support many changes in recent MCP spec update.
https://modelcontextprotocol.io/specification/2025-06-18/changelog

How Has This Been Tested?

• New unit tests
• MCP Inspector npx @modelcontextprotocol/inspector@latest

Breaking Changes

• New case on public enum Tool.Content.resourceLink
• Updated associated values on enum case Tool.Content.resource to include optional title and annoations properties

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)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

_meta is not a Swifty name but does map nicely to the spec. Open to suggestions

[alainakafkes]

hi there and thank you for taking a stab at supporting the latest MCP spec! i saw this PR because i am hoping to use Result's structuredOutput for a project. i have no special role in this repo but wanted to offer some feedback to help build interest in this work

[ajevans99]

hi there and thank you for taking a stab at supporting the latest MCP spec! i saw this PR because i am hoping to use Result's structuredOutput for a project. i have no special role in this repo but wanted to offer some feedback to help build interest in this work

Thanks for the early review. Implemented a bunch of your suggestions and re-thought the meta and general fields.

[aehlke]

I see you had some changes last week. Is this ready to use as a fork until it gets reviewed? I hope this will be merged if it is ready. Thanks!

[ajevans99]

I see you had some changes last week. Is this ready to use as a fork until it gets reviewed? I hope this will be merged if it is ready. Thanks!

Ready on my side. @mattt could we get a review when you get a chance

[movetz]

Hi folks! @ajevans99@aehlke@alainakafkes

Can we continue in the official Discord and swift-sdk-dev channel? You can find the link on the official site community section.

Actually, we (at @MacPaw) have made almost the same updates in our private fork and are planning the next changes for the latest version. It makes more sense to combine our work and move faster. And it will be great if we can discuss it 🙏.

[aehlke]

Just to note for those who find this here - on Discord the latest is that there will be an online meeting on Jan 9th where this project's maintenance status and stewardship may be discussed (by those here who are stepping up to raise the topic and make proposals)

[DePasqualeOrg]

Thanks for your contribution, @ajevans99. Since my PR #175, which I developed independently, overlaps with this one, I wanted to explain some of the differences between the two. If you think I've missed something, or if you have any feedback on my PR, please let me know.

My PR fully implements all the required _meta and extraFields support. I chose a simpler approach by omitting _meta key validation, which neither the TypeScript nor the Python SDK implements.

Comparison

Feature	Spec	PR #167	TS SDK	Python SDK	My PR #175
_meta on Result types	Required	✅	✅	✅	✅
_meta on RequestParams	Required	✅	✅	✅	✅
_meta on NotificationParams	Required	✅	✅	✅	✅
_meta on content types	Required	✅	✅	✅	✅
_meta on entity types	Required	✅	✅	✅	✅
extraFields on Results	Required	✅	✅	✅	✅
_meta key validation	Not in schema	✅	❌	❌	❌
title fields	Required	✅	✅	✅	✅
outputSchema on Tool	Required	✅	✅	✅	✅
ResourceLink	Required	✅	✅	✅	✅
Icons	2025-11-25	❌	✅	✅	✅
Tasks	2025-11-25	❌	✅	✅	✅
URL elicitation	2025-11-25	❌	✅	✅	✅
Full elicitation impl	Required	Types only	✅	✅	✅
Protocol version	—	2025-06-18	2025-11-25	2025-11-25	2025-11-25

Differences in my PR #175

No _meta key validation: This PR adds ~200 lines to validate _meta key formats. I omitted this because the JSON Schema uses additionalProperties: {} with no format constraints, and the Python and TypeScript SDKs don't validate keys.

ResultWithExtraFields protocol: I use a protocol with default implementations for consistent extraFields decoding across all Result types, which reduces code duplication.

RequestMeta type: Captures progressToken plus arbitrary additional fields, matching how the TypeScript and Python SDKs handle request metadata.

Flattened Task results: GetTask.Result and CancelTask.Result flatten Task fields per the spec's allOf[Result, Task], matching TS (Result & Task) and Python (class GetTaskResult(Result, Task)).

2025-11-25 support: I support the latest protocol version, including Tasks, Icons, and URL elicitation.

[movetz]

@ajevans99 Big thx! You covered many things, and the changes are aligned with the current architecture. We decided to merge it and reuse it for the next changes. We open for any help and contributions and will mention you in the official Discord channel.

[ajevans99]

Added/Changed

• Add support for structured tool output (PR #371)
• Add support for elicitation, enabling servers to request additional information from users during interactions. (PR #382) Requires server to client implementation, types only for now
• Add support for resource links in tool call results. (PR #603)
• Add _meta field to additional interface types (PR #710), and specify proper usage. Also adds extraFields to allow [key: string]: unknown; on __Result types align with interfaces/schema https://modelcontextprotocol.io/specification/2025-06-18/schema_
• Add title field for human-friendly display names, so that name can be used as a programmatic identifier (PR #663)

Not Handled

• Remove support for JSON-RPC batching (PR #416)
• Require negotiated protocol version to be specified via MCP-Protocol-Version header in subsequent requests when using HTTP (PR #548).
• Add context field to CompletionRequest, providing for completion requests to include previously-resolved variables (PR #598).

Motivation and Context

Support many changes in recent MCP spec update.
https://modelcontextprotocol.io/specification/2025-06-18/changelog

How Has This Been Tested?

• New unit tests
• MCP Inspector npx @modelcontextprotocol/inspector@latest

Breaking Changes

• New case on public enum Tool.Content.resourceLink
• Updated associated values on enum case Tool.Content.resource to include optional title and annoations properties

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)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

_meta is not a Swifty name but does map nicely to the spec. Open to suggestions

[alainakafkes]

hi there and thank you for taking a stab at supporting the latest MCP spec! i saw this PR because i am hoping to use Result's structuredOutput for a project. i have no special role in this repo but wanted to offer some feedback to help build interest in this work

[ajevans99]

hi there and thank you for taking a stab at supporting the latest MCP spec! i saw this PR because i am hoping to use Result's structuredOutput for a project. i have no special role in this repo but wanted to offer some feedback to help build interest in this work

Thanks for the early review. Implemented a bunch of your suggestions and re-thought the meta and general fields.

[aehlke]

I see you had some changes last week. Is this ready to use as a fork until it gets reviewed? I hope this will be merged if it is ready. Thanks!

[ajevans99]

I see you had some changes last week. Is this ready to use as a fork until it gets reviewed? I hope this will be merged if it is ready. Thanks!

Ready on my side. @mattt could we get a review when you get a chance

[movetz]

Hi folks! @ajevans99@aehlke@alainakafkes

Can we continue in the official Discord and swift-sdk-dev channel? You can find the link on the official site community section.

Actually, we (at @MacPaw) have made almost the same updates in our private fork and are planning the next changes for the latest version. It makes more sense to combine our work and move faster. And it will be great if we can discuss it 🙏.

[aehlke]

Just to note for those who find this here - on Discord the latest is that there will be an online meeting on Jan 9th where this project's maintenance status and stewardship may be discussed (by those here who are stepping up to raise the topic and make proposals)

[DePasqualeOrg]

Thanks for your contribution, @ajevans99. Since my PR #175, which I developed independently, overlaps with this one, I wanted to explain some of the differences between the two. If you think I've missed something, or if you have any feedback on my PR, please let me know.

My PR fully implements all the required _meta and extraFields support. I chose a simpler approach by omitting _meta key validation, which neither the TypeScript nor the Python SDK implements.

Comparison

Feature	Spec	PR #167	TS SDK	Python SDK	My PR #175
_meta on Result types	Required	✅	✅	✅	✅
_meta on RequestParams	Required	✅	✅	✅	✅
_meta on NotificationParams	Required	✅	✅	✅	✅
_meta on content types	Required	✅	✅	✅	✅
_meta on entity types	Required	✅	✅	✅	✅
extraFields on Results	Required	✅	✅	✅	✅
_meta key validation	Not in schema	✅	❌	❌	❌
title fields	Required	✅	✅	✅	✅
outputSchema on Tool	Required	✅	✅	✅	✅
ResourceLink	Required	✅	✅	✅	✅
Icons	2025-11-25	❌	✅	✅	✅
Tasks	2025-11-25	❌	✅	✅	✅
URL elicitation	2025-11-25	❌	✅	✅	✅
Full elicitation impl	Required	Types only	✅	✅	✅
Protocol version	—	2025-06-18	2025-11-25	2025-11-25	2025-11-25

Differences in my PR #175

No _meta key validation: This PR adds ~200 lines to validate _meta key formats. I omitted this because the JSON Schema uses additionalProperties: {} with no format constraints, and the Python and TypeScript SDKs don't validate keys.

ResultWithExtraFields protocol: I use a protocol with default implementations for consistent extraFields decoding across all Result types, which reduces code duplication.

RequestMeta type: Captures progressToken plus arbitrary additional fields, matching how the TypeScript and Python SDKs handle request metadata.

Flattened Task results: GetTask.Result and CancelTask.Result flatten Task fields per the spec's allOf[Result, Task], matching TS (Result & Task) and Python (class GetTaskResult(Result, Task)).

2025-11-25 support: I support the latest protocol version, including Tasks, Icons, and URL elicitation.

[movetz]

@ajevans99 Big thx! You covered many things, and the changes are aligned with the current architecture. We decided to merge it and reuse it for the next changes. We open for any help and contributions and will mention you in the official Discord channel.

[ajevans99]

Added/Changed

• Add support for structured tool output (PR #371)
• Add support for elicitation, enabling servers to request additional information from users during interactions. (PR #382) Requires server to client implementation, types only for now
• Add support for resource links in tool call results. (PR #603)
• Add _meta field to additional interface types (PR #710), and specify proper usage. Also adds extraFields to allow [key: string]: unknown; on __Result types align with interfaces/schema https://modelcontextprotocol.io/specification/2025-06-18/schema_
• Add title field for human-friendly display names, so that name can be used as a programmatic identifier (PR #663)

Not Handled

• Remove support for JSON-RPC batching (PR #416)
• Require negotiated protocol version to be specified via MCP-Protocol-Version header in subsequent requests when using HTTP (PR #548).
• Add context field to CompletionRequest, providing for completion requests to include previously-resolved variables (PR #598).

Motivation and Context

Support many changes in recent MCP spec update.
https://modelcontextprotocol.io/specification/2025-06-18/changelog

How Has This Been Tested?

• New unit tests
• MCP Inspector npx @modelcontextprotocol/inspector@latest

Breaking Changes

• New case on public enum Tool.Content.resourceLink
• Updated associated values on enum case Tool.Content.resource to include optional title and annoations properties

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)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

_meta is not a Swifty name but does map nicely to the spec. Open to suggestions

[alainakafkes]

hi there and thank you for taking a stab at supporting the latest MCP spec! i saw this PR because i am hoping to use Result's structuredOutput for a project. i have no special role in this repo but wanted to offer some feedback to help build interest in this work

[ajevans99]

hi there and thank you for taking a stab at supporting the latest MCP spec! i saw this PR because i am hoping to use Result's structuredOutput for a project. i have no special role in this repo but wanted to offer some feedback to help build interest in this work

Thanks for the early review. Implemented a bunch of your suggestions and re-thought the meta and general fields.

[aehlke]

I see you had some changes last week. Is this ready to use as a fork until it gets reviewed? I hope this will be merged if it is ready. Thanks!

[ajevans99]

I see you had some changes last week. Is this ready to use as a fork until it gets reviewed? I hope this will be merged if it is ready. Thanks!

Ready on my side. @mattt could we get a review when you get a chance

[movetz]

Hi folks! @ajevans99@aehlke@alainakafkes

Can we continue in the official Discord and swift-sdk-dev channel? You can find the link on the official site community section.

Actually, we (at @MacPaw) have made almost the same updates in our private fork and are planning the next changes for the latest version. It makes more sense to combine our work and move faster. And it will be great if we can discuss it 🙏.

[aehlke]

Just to note for those who find this here - on Discord the latest is that there will be an online meeting on Jan 9th where this project's maintenance status and stewardship may be discussed (by those here who are stepping up to raise the topic and make proposals)

[DePasqualeOrg]

Thanks for your contribution, @ajevans99. Since my PR #175, which I developed independently, overlaps with this one, I wanted to explain some of the differences between the two. If you think I've missed something, or if you have any feedback on my PR, please let me know.

My PR fully implements all the required _meta and extraFields support. I chose a simpler approach by omitting _meta key validation, which neither the TypeScript nor the Python SDK implements.

Comparison

Feature	Spec	PR #167	TS SDK	Python SDK	My PR #175
_meta on Result types	Required	✅	✅	✅	✅
_meta on RequestParams	Required	✅	✅	✅	✅
_meta on NotificationParams	Required	✅	✅	✅	✅
_meta on content types	Required	✅	✅	✅	✅
_meta on entity types	Required	✅	✅	✅	✅
extraFields on Results	Required	✅	✅	✅	✅
_meta key validation	Not in schema	✅	❌	❌	❌
title fields	Required	✅	✅	✅	✅
outputSchema on Tool	Required	✅	✅	✅	✅
ResourceLink	Required	✅	✅	✅	✅
Icons	2025-11-25	❌	✅	✅	✅
Tasks	2025-11-25	❌	✅	✅	✅
URL elicitation	2025-11-25	❌	✅	✅	✅
Full elicitation impl	Required	Types only	✅	✅	✅
Protocol version	—	2025-06-18	2025-11-25	2025-11-25	2025-11-25

Differences in my PR #175

No _meta key validation: This PR adds ~200 lines to validate _meta key formats. I omitted this because the JSON Schema uses additionalProperties: {} with no format constraints, and the Python and TypeScript SDKs don't validate keys.

ResultWithExtraFields protocol: I use a protocol with default implementations for consistent extraFields decoding across all Result types, which reduces code duplication.

RequestMeta type: Captures progressToken plus arbitrary additional fields, matching how the TypeScript and Python SDKs handle request metadata.

Flattened Task results: GetTask.Result and CancelTask.Result flatten Task fields per the spec's allOf[Result, Task], matching TS (Result & Task) and Python (class GetTaskResult(Result, Task)).

2025-11-25 support: I support the latest protocol version, including Tasks, Icons, and URL elicitation.

[movetz]

@ajevans99 Big thx! You covered many things, and the changes are aligned with the current architecture. We decided to merge it and reuse it for the next changes. We open for any help and contributions and will mention you in the official Discord channel.

[ajevans99]

Added/Changed

• Add support for structured tool output (PR #371)
• Add support for elicitation, enabling servers to request additional information from users during interactions. (PR #382) Requires server to client implementation, types only for now
• Add support for resource links in tool call results. (PR #603)
• Add _meta field to additional interface types (PR #710), and specify proper usage. Also adds extraFields to allow [key: string]: unknown; on __Result types align with interfaces/schema https://modelcontextprotocol.io/specification/2025-06-18/schema_
• Add title field for human-friendly display names, so that name can be used as a programmatic identifier (PR #663)

Not Handled

• Remove support for JSON-RPC batching (PR #416)
• Require negotiated protocol version to be specified via MCP-Protocol-Version header in subsequent requests when using HTTP (PR #548).
• Add context field to CompletionRequest, providing for completion requests to include previously-resolved variables (PR #598).

Motivation and Context

Support many changes in recent MCP spec update.
https://modelcontextprotocol.io/specification/2025-06-18/changelog

How Has This Been Tested?

• New unit tests
• MCP Inspector npx @modelcontextprotocol/inspector@latest

Breaking Changes

• New case on public enum Tool.Content.resourceLink
• Updated associated values on enum case Tool.Content.resource to include optional title and annoations properties

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)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

_meta is not a Swifty name but does map nicely to the spec. Open to suggestions

[alainakafkes]

hi there and thank you for taking a stab at supporting the latest MCP spec! i saw this PR because i am hoping to use Result's structuredOutput for a project. i have no special role in this repo but wanted to offer some feedback to help build interest in this work

[ajevans99]

hi there and thank you for taking a stab at supporting the latest MCP spec! i saw this PR because i am hoping to use Result's structuredOutput for a project. i have no special role in this repo but wanted to offer some feedback to help build interest in this work

Thanks for the early review. Implemented a bunch of your suggestions and re-thought the meta and general fields.

[aehlke]

I see you had some changes last week. Is this ready to use as a fork until it gets reviewed? I hope this will be merged if it is ready. Thanks!

[ajevans99]

I see you had some changes last week. Is this ready to use as a fork until it gets reviewed? I hope this will be merged if it is ready. Thanks!

Ready on my side. @mattt could we get a review when you get a chance

[movetz]

Hi folks! @ajevans99@aehlke@alainakafkes

Can we continue in the official Discord and swift-sdk-dev channel? You can find the link on the official site community section.

Actually, we (at @MacPaw) have made almost the same updates in our private fork and are planning the next changes for the latest version. It makes more sense to combine our work and move faster. And it will be great if we can discuss it 🙏.

[aehlke]

Just to note for those who find this here - on Discord the latest is that there will be an online meeting on Jan 9th where this project's maintenance status and stewardship may be discussed (by those here who are stepping up to raise the topic and make proposals)

[DePasqualeOrg]

Thanks for your contribution, @ajevans99. Since my PR #175, which I developed independently, overlaps with this one, I wanted to explain some of the differences between the two. If you think I've missed something, or if you have any feedback on my PR, please let me know.

My PR fully implements all the required _meta and extraFields support. I chose a simpler approach by omitting _meta key validation, which neither the TypeScript nor the Python SDK implements.

Comparison

Feature	Spec	PR #167	TS SDK	Python SDK	My PR #175
_meta on Result types	Required	✅	✅	✅	✅
_meta on RequestParams	Required	✅	✅	✅	✅
_meta on NotificationParams	Required	✅	✅	✅	✅
_meta on content types	Required	✅	✅	✅	✅
_meta on entity types	Required	✅	✅	✅	✅
extraFields on Results	Required	✅	✅	✅	✅
_meta key validation	Not in schema	✅	❌	❌	❌
title fields	Required	✅	✅	✅	✅
outputSchema on Tool	Required	✅	✅	✅	✅
ResourceLink	Required	✅	✅	✅	✅
Icons	2025-11-25	❌	✅	✅	✅
Tasks	2025-11-25	❌	✅	✅	✅
URL elicitation	2025-11-25	❌	✅	✅	✅
Full elicitation impl	Required	Types only	✅	✅	✅
Protocol version	—	2025-06-18	2025-11-25	2025-11-25	2025-11-25

Differences in my PR #175

No _meta key validation: This PR adds ~200 lines to validate _meta key formats. I omitted this because the JSON Schema uses additionalProperties: {} with no format constraints, and the Python and TypeScript SDKs don't validate keys.

ResultWithExtraFields protocol: I use a protocol with default implementations for consistent extraFields decoding across all Result types, which reduces code duplication.

RequestMeta type: Captures progressToken plus arbitrary additional fields, matching how the TypeScript and Python SDKs handle request metadata.

Flattened Task results: GetTask.Result and CancelTask.Result flatten Task fields per the spec's allOf[Result, Task], matching TS (Result & Task) and Python (class GetTaskResult(Result, Task)).

2025-11-25 support: I support the latest protocol version, including Tasks, Icons, and URL elicitation.

[movetz]

@ajevans99 Big thx! You covered many things, and the changes are aligned with the current architecture. We decided to merge it and reuse it for the next changes. We open for any help and contributions and will mention you in the official Discord channel.

[ajevans99]

Added/Changed

• Add support for structured tool output (PR #371)
• Add support for elicitation, enabling servers to request additional information from users during interactions. (PR #382) Requires server to client implementation, types only for now
• Add support for resource links in tool call results. (PR #603)
• Add _meta field to additional interface types (PR #710), and specify proper usage. Also adds extraFields to allow [key: string]: unknown; on __Result types align with interfaces/schema https://modelcontextprotocol.io/specification/2025-06-18/schema_
• Add title field for human-friendly display names, so that name can be used as a programmatic identifier (PR #663)

Not Handled

• Remove support for JSON-RPC batching (PR #416)
• Require negotiated protocol version to be specified via MCP-Protocol-Version header in subsequent requests when using HTTP (PR #548).
• Add context field to CompletionRequest, providing for completion requests to include previously-resolved variables (PR #598).

Motivation and Context

Support many changes in recent MCP spec update.
https://modelcontextprotocol.io/specification/2025-06-18/changelog

How Has This Been Tested?

• New unit tests
• MCP Inspector npx @modelcontextprotocol/inspector@latest

Breaking Changes

• New case on public enum Tool.Content.resourceLink
• Updated associated values on enum case Tool.Content.resource to include optional title and annoations properties

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)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

_meta is not a Swifty name but does map nicely to the spec. Open to suggestions

[alainakafkes]

hi there and thank you for taking a stab at supporting the latest MCP spec! i saw this PR because i am hoping to use Result's structuredOutput for a project. i have no special role in this repo but wanted to offer some feedback to help build interest in this work

[ajevans99]

hi there and thank you for taking a stab at supporting the latest MCP spec! i saw this PR because i am hoping to use Result's structuredOutput for a project. i have no special role in this repo but wanted to offer some feedback to help build interest in this work

Thanks for the early review. Implemented a bunch of your suggestions and re-thought the meta and general fields.

[aehlke]

I see you had some changes last week. Is this ready to use as a fork until it gets reviewed? I hope this will be merged if it is ready. Thanks!

[ajevans99]

I see you had some changes last week. Is this ready to use as a fork until it gets reviewed? I hope this will be merged if it is ready. Thanks!

Ready on my side. @mattt could we get a review when you get a chance

[movetz]

Hi folks! @ajevans99@aehlke@alainakafkes

Can we continue in the official Discord and swift-sdk-dev channel? You can find the link on the official site community section.

Actually, we (at @MacPaw) have made almost the same updates in our private fork and are planning the next changes for the latest version. It makes more sense to combine our work and move faster. And it will be great if we can discuss it 🙏.

[aehlke]

Just to note for those who find this here - on Discord the latest is that there will be an online meeting on Jan 9th where this project's maintenance status and stewardship may be discussed (by those here who are stepping up to raise the topic and make proposals)

[DePasqualeOrg]

Thanks for your contribution, @ajevans99. Since my PR #175, which I developed independently, overlaps with this one, I wanted to explain some of the differences between the two. If you think I've missed something, or if you have any feedback on my PR, please let me know.

My PR fully implements all the required _meta and extraFields support. I chose a simpler approach by omitting _meta key validation, which neither the TypeScript nor the Python SDK implements.

Comparison

Feature	Spec	PR #167	TS SDK	Python SDK	My PR #175
_meta on Result types	Required	✅	✅	✅	✅
_meta on RequestParams	Required	✅	✅	✅	✅
_meta on NotificationParams	Required	✅	✅	✅	✅
_meta on content types	Required	✅	✅	✅	✅
_meta on entity types	Required	✅	✅	✅	✅
extraFields on Results	Required	✅	✅	✅	✅
_meta key validation	Not in schema	✅	❌	❌	❌
title fields	Required	✅	✅	✅	✅
outputSchema on Tool	Required	✅	✅	✅	✅
ResourceLink	Required	✅	✅	✅	✅
Icons	2025-11-25	❌	✅	✅	✅
Tasks	2025-11-25	❌	✅	✅	✅
URL elicitation	2025-11-25	❌	✅	✅	✅
Full elicitation impl	Required	Types only	✅	✅	✅
Protocol version	—	2025-06-18	2025-11-25	2025-11-25	2025-11-25

Differences in my PR #175

No _meta key validation: This PR adds ~200 lines to validate _meta key formats. I omitted this because the JSON Schema uses additionalProperties: {} with no format constraints, and the Python and TypeScript SDKs don't validate keys.

ResultWithExtraFields protocol: I use a protocol with default implementations for consistent extraFields decoding across all Result types, which reduces code duplication.

RequestMeta type: Captures progressToken plus arbitrary additional fields, matching how the TypeScript and Python SDKs handle request metadata.

Flattened Task results: GetTask.Result and CancelTask.Result flatten Task fields per the spec's allOf[Result, Task], matching TS (Result & Task) and Python (class GetTaskResult(Result, Task)).

2025-11-25 support: I support the latest protocol version, including Tasks, Icons, and URL elicitation.

[movetz]

@ajevans99 Big thx! You covered many things, and the changes are aligned with the current architecture. We decided to merge it and reuse it for the next changes. We open for any help and contributions and will mention you in the official Discord channel.

[ajevans99]

Added/Changed

• Add support for structured tool output (PR #371)
• Add support for elicitation, enabling servers to request additional information from users during interactions. (PR #382) Requires server to client implementation, types only for now
• Add support for resource links in tool call results. (PR #603)
• Add _meta field to additional interface types (PR #710), and specify proper usage. Also adds extraFields to allow [key: string]: unknown; on __Result types align with interfaces/schema https://modelcontextprotocol.io/specification/2025-06-18/schema_
• Add title field for human-friendly display names, so that name can be used as a programmatic identifier (PR #663)

Not Handled

• Remove support for JSON-RPC batching (PR #416)
• Require negotiated protocol version to be specified via MCP-Protocol-Version header in subsequent requests when using HTTP (PR #548).
• Add context field to CompletionRequest, providing for completion requests to include previously-resolved variables (PR #598).

Motivation and Context

Support many changes in recent MCP spec update.
https://modelcontextprotocol.io/specification/2025-06-18/changelog

How Has This Been Tested?

• New unit tests
• MCP Inspector npx @modelcontextprotocol/inspector@latest

Breaking Changes

• New case on public enum Tool.Content.resourceLink
• Updated associated values on enum case Tool.Content.resource to include optional title and annoations properties

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)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

_meta is not a Swifty name but does map nicely to the spec. Open to suggestions

[alainakafkes]

hi there and thank you for taking a stab at supporting the latest MCP spec! i saw this PR because i am hoping to use Result's structuredOutput for a project. i have no special role in this repo but wanted to offer some feedback to help build interest in this work

[ajevans99]

hi there and thank you for taking a stab at supporting the latest MCP spec! i saw this PR because i am hoping to use Result's structuredOutput for a project. i have no special role in this repo but wanted to offer some feedback to help build interest in this work

Thanks for the early review. Implemented a bunch of your suggestions and re-thought the meta and general fields.

[aehlke]

I see you had some changes last week. Is this ready to use as a fork until it gets reviewed? I hope this will be merged if it is ready. Thanks!

[ajevans99]

I see you had some changes last week. Is this ready to use as a fork until it gets reviewed? I hope this will be merged if it is ready. Thanks!

Ready on my side. @mattt could we get a review when you get a chance

[movetz]

Hi folks! @ajevans99@aehlke@alainakafkes

Can we continue in the official Discord and swift-sdk-dev channel? You can find the link on the official site community section.

Actually, we (at @MacPaw) have made almost the same updates in our private fork and are planning the next changes for the latest version. It makes more sense to combine our work and move faster. And it will be great if we can discuss it 🙏.

[aehlke]

Just to note for those who find this here - on Discord the latest is that there will be an online meeting on Jan 9th where this project's maintenance status and stewardship may be discussed (by those here who are stepping up to raise the topic and make proposals)

[DePasqualeOrg]

Thanks for your contribution, @ajevans99. Since my PR #175, which I developed independently, overlaps with this one, I wanted to explain some of the differences between the two. If you think I've missed something, or if you have any feedback on my PR, please let me know.

My PR fully implements all the required _meta and extraFields support. I chose a simpler approach by omitting _meta key validation, which neither the TypeScript nor the Python SDK implements.

Comparison

Feature	Spec	PR #167	TS SDK	Python SDK	My PR #175
_meta on Result types	Required	✅	✅	✅	✅
_meta on RequestParams	Required	✅	✅	✅	✅
_meta on NotificationParams	Required	✅	✅	✅	✅
_meta on content types	Required	✅	✅	✅	✅
_meta on entity types	Required	✅	✅	✅	✅
extraFields on Results	Required	✅	✅	✅	✅
_meta key validation	Not in schema	✅	❌	❌	❌
title fields	Required	✅	✅	✅	✅
outputSchema on Tool	Required	✅	✅	✅	✅
ResourceLink	Required	✅	✅	✅	✅
Icons	2025-11-25	❌	✅	✅	✅
Tasks	2025-11-25	❌	✅	✅	✅
URL elicitation	2025-11-25	❌	✅	✅	✅
Full elicitation impl	Required	Types only	✅	✅	✅
Protocol version	—	2025-06-18	2025-11-25	2025-11-25	2025-11-25

Differences in my PR #175

No _meta key validation: This PR adds ~200 lines to validate _meta key formats. I omitted this because the JSON Schema uses additionalProperties: {} with no format constraints, and the Python and TypeScript SDKs don't validate keys.

ResultWithExtraFields protocol: I use a protocol with default implementations for consistent extraFields decoding across all Result types, which reduces code duplication.

RequestMeta type: Captures progressToken plus arbitrary additional fields, matching how the TypeScript and Python SDKs handle request metadata.

Flattened Task results: GetTask.Result and CancelTask.Result flatten Task fields per the spec's allOf[Result, Task], matching TS (Result & Task) and Python (class GetTaskResult(Result, Task)).

2025-11-25 support: I support the latest protocol version, including Tasks, Icons, and URL elicitation.

[movetz]

@ajevans99 Big thx! You covered many things, and the changes are aligned with the current architecture. We decided to merge it and reuse it for the next changes. We open for any help and contributions and will mention you in the official Discord channel.

[ajevans99]

Added/Changed

• Add support for structured tool output (PR #371)
• Add support for elicitation, enabling servers to request additional information from users during interactions. (PR #382) Requires server to client implementation, types only for now
• Add support for resource links in tool call results. (PR #603)
• Add _meta field to additional interface types (PR #710), and specify proper usage. Also adds extraFields to allow [key: string]: unknown; on __Result types align with interfaces/schema https://modelcontextprotocol.io/specification/2025-06-18/schema_
• Add title field for human-friendly display names, so that name can be used as a programmatic identifier (PR #663)

Not Handled

• Remove support for JSON-RPC batching (PR #416)
• Require negotiated protocol version to be specified via MCP-Protocol-Version header in subsequent requests when using HTTP (PR #548).
• Add context field to CompletionRequest, providing for completion requests to include previously-resolved variables (PR #598).

Motivation and Context

Support many changes in recent MCP spec update.
https://modelcontextprotocol.io/specification/2025-06-18/changelog

How Has This Been Tested?

• New unit tests
• MCP Inspector npx @modelcontextprotocol/inspector@latest

Breaking Changes

• New case on public enum Tool.Content.resourceLink
• Updated associated values on enum case Tool.Content.resource to include optional title and annoations properties

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)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

_meta is not a Swifty name but does map nicely to the spec. Open to suggestions

[alainakafkes]

hi there and thank you for taking a stab at supporting the latest MCP spec! i saw this PR because i am hoping to use Result's structuredOutput for a project. i have no special role in this repo but wanted to offer some feedback to help build interest in this work

[ajevans99]

hi there and thank you for taking a stab at supporting the latest MCP spec! i saw this PR because i am hoping to use Result's structuredOutput for a project. i have no special role in this repo but wanted to offer some feedback to help build interest in this work

Thanks for the early review. Implemented a bunch of your suggestions and re-thought the meta and general fields.

[aehlke]

I see you had some changes last week. Is this ready to use as a fork until it gets reviewed? I hope this will be merged if it is ready. Thanks!

[ajevans99]

I see you had some changes last week. Is this ready to use as a fork until it gets reviewed? I hope this will be merged if it is ready. Thanks!

Ready on my side. @mattt could we get a review when you get a chance

[movetz]

Hi folks! @ajevans99@aehlke@alainakafkes

Can we continue in the official Discord and swift-sdk-dev channel? You can find the link on the official site community section.

Actually, we (at @MacPaw) have made almost the same updates in our private fork and are planning the next changes for the latest version. It makes more sense to combine our work and move faster. And it will be great if we can discuss it 🙏.

[aehlke]

Just to note for those who find this here - on Discord the latest is that there will be an online meeting on Jan 9th where this project's maintenance status and stewardship may be discussed (by those here who are stepping up to raise the topic and make proposals)

[DePasqualeOrg]

Thanks for your contribution, @ajevans99. Since my PR #175, which I developed independently, overlaps with this one, I wanted to explain some of the differences between the two. If you think I've missed something, or if you have any feedback on my PR, please let me know.

My PR fully implements all the required _meta and extraFields support. I chose a simpler approach by omitting _meta key validation, which neither the TypeScript nor the Python SDK implements.

Comparison

Feature	Spec	PR #167	TS SDK	Python SDK	My PR #175
_meta on Result types	Required	✅	✅	✅	✅
_meta on RequestParams	Required	✅	✅	✅	✅
_meta on NotificationParams	Required	✅	✅	✅	✅
_meta on content types	Required	✅	✅	✅	✅
_meta on entity types	Required	✅	✅	✅	✅
extraFields on Results	Required	✅	✅	✅	✅
_meta key validation	Not in schema	✅	❌	❌	❌
title fields	Required	✅	✅	✅	✅
outputSchema on Tool	Required	✅	✅	✅	✅
ResourceLink	Required	✅	✅	✅	✅
Icons	2025-11-25	❌	✅	✅	✅
Tasks	2025-11-25	❌	✅	✅	✅
URL elicitation	2025-11-25	❌	✅	✅	✅
Full elicitation impl	Required	Types only	✅	✅	✅
Protocol version	—	2025-06-18	2025-11-25	2025-11-25	2025-11-25

Differences in my PR #175

No _meta key validation: This PR adds ~200 lines to validate _meta key formats. I omitted this because the JSON Schema uses additionalProperties: {} with no format constraints, and the Python and TypeScript SDKs don't validate keys.

ResultWithExtraFields protocol: I use a protocol with default implementations for consistent extraFields decoding across all Result types, which reduces code duplication.

RequestMeta type: Captures progressToken plus arbitrary additional fields, matching how the TypeScript and Python SDKs handle request metadata.

Flattened Task results: GetTask.Result and CancelTask.Result flatten Task fields per the spec's allOf[Result, Task], matching TS (Result & Task) and Python (class GetTaskResult(Result, Task)).

2025-11-25 support: I support the latest protocol version, including Tasks, Icons, and URL elicitation.

[movetz]

@ajevans99 Big thx! You covered many things, and the changes are aligned with the current architecture. We decided to merge it and reuse it for the next changes. We open for any help and contributions and will mention you in the official Discord channel.