MCP Swift SDK: the official Swift implementation of Model Context Protocol

What the MCP Swift SDK is for

Model Context Protocol standardises how an application talks to AI and ML models, and this repository is the official Swift implementation of that protocol. It ships both halves: a client that connects to MCP servers, and a server that exposes capabilities to MCP clients. Both are implemented against the 2025-11-25 revision of the specification, which the README calls the latest version.

The audience is narrow and specific. You need Swift 6.0 or later, which in practice means Xcode 16 or newer, and you need a reason to be in Swift rather than Python or TypeScript. That reason usually exists on Apple platforms: a macOS app that wants to consume tools from a local MCP server, or an iOS or server-side Swift process that wants to publish tools, resources and prompts to whatever MCP client connects to it. If you are writing a quick integration script, this SDK is more ceremony than the task deserves.

Client and server in one package, over pluggable transports

The architecture splits cleanly into a protocol layer and a transport layer. A Client is constructed with a name and version, then connected to a transport. The connect call returns an initialization result whose capabilities field tells you what the peer supports, and the README notes that this return value is discardable, so you can ignore it when you do not need to branch on capabilities.

Transports are the interesting part. StdioTransport spawns local subprocess communication, which is the simplest option and the one the README presents first. HTTPClientTransport takes an endpoint URL and a streaming flag; setting streaming to true enables Server-Sent Events for real-time updates. That flag is the difference between request-response polling and a live channel, and it is a client-side decision you make at construction time.

Above the transport, the SDK models MCP's primitives directly. Tools are listed with listTools and invoked with callTool, which returns content plus an isError flag. Tool results are an enum you switch over: text, image with data and MIME type and optional metadata, audio, embedded resource, and resourceLink. Resources are listed, read by URI, and can be subscribed to when the server advertises the subscribe capability, with updates arriving through onNotification handlers. Prompts are templated conversation starters retrieved by name with arguments. The client surface also covers completions, sampling, elicitation, roots, logging, error handling, cancellation and progress tracking, which is a wider feature set than most people expect from a first look at the README.

Installing the MCP Swift SDK with Swift Package Manager

There is no installer and no CLI. Distribution is through Swift Package Manager, and the README gives the dependency declaration directly. Add the package to your Package.swift using the repository URL and a version requirement; the README's example pins from 0.11.0.

dependencies: [
    .package(url: "https://github.com/modelcontextprotocol/swift-sdk.git", from: "0.11.0")
]

Then declare the product on your target. The product name is MCP and the package name is swift-sdk, which is the part people get wrong when copying the URL.

.target(
    name: "YourTarget",
    dependencies: [
        .product(name: "MCP", package: "swift-sdk")
    ]
)

A first real use is a client that connects over stdio and lists the tools the server offers. The README's basic setup imports MCP, constructs a Client with a name and version, creates a StdioTransport, and awaits connect. The returned result carries capabilities, and the README shows checking result.capabilities.tools before assuming tool support. After that, listTools returns a tuple of tools and a cursor, and printing the mapped names is enough to confirm the connection works end to end.

import MCP

let client = Client(name: "MyApp", version: "1.0.0")
let transport = StdioTransport()
let result = try await client.connect(transport: transport)

if result.capabilities.tools != nil {
    let (tools, cursor) = try await client.listTools()
    print("Available tools: \(tools.map { $0.name }.joined(separator: ", "))")
}

If you need a remote server instead, swap in HTTPClientTransport with the endpoint URL and streaming set to true. Everything above the transport stays the same, which is the point of the split.

Platform availability is the real constraint

The README keeps platform requirements in their own section rather than in Requirements, and that separation is honest: Swift 6.0 and Xcode 16 are the language floor, but where the SDK actually runs depends on the Platform Availability list, which the README does not reproduce in its opening. Anyone planning a Linux server-side deployment, a Windows build, or an Android target should read that section before writing code, because the answer is not in the Requirements block.

The second limitation is maturity. The release history runs 0.11.0 in February 2026, 0.12.0 in March, and 0.12.1 in May. Three minor releases in three months on a pre-1.0 version means the API is still moving. The README's own install example still pins from 0.11.0, which is behind the current release, and that gap is a useful signal about how quickly the documentation tracks the code.

The third is scope. This is an SDK, not an application. There is no bundled server to run, no inspector UI, and no tooling beyond the conformance-baseline.yml and scripts directory visible in the repository layout. If you want to poke at an MCP server interactively, you will be writing that harness yourself.

How this differs from the Python and TypeScript MCP SDKs

The obvious alternative is the official MCP SDK for another language, most often Python or TypeScript. The protocol is the same and the primitive model maps closely, so the choice is rarely about capability. It is about where your code already lives.

The difference in approach shows up in the type system and in concurrency. This SDK leans on Swift 6's structured concurrency: connect is async and throwing, notifications arrive through onNotification handlers, and tool content is a Swift enum you exhaustively switch over. In a dynamically typed SDK the same code is a dictionary lookup and a runtime check. That is a genuine trade: the Swift version catches shape errors at compile time and costs you more code to express the same flow. If your team is not already fluent in Swift 6 concurrency, the Python or TypeScript SDK will get you to a working integration faster, and nothing about this package changes that.

Maintenance, versions and licence

The repository is not archived. The last push was on 2026-05-07, which is more than six months before today, and the 0.12.1 release carries the same timestamp. There is no sign of development after that date in the repository metadata, so treat the current release as the state of the project rather than the start of a cadence.

Upgrade cost is the practical concern. Moving between 0.11.0 and 0.12.x is a minor version bump on a pre-1.0 package, and the README's install snippet still references 0.11.0, so you cannot assume the documentation has been revised for every change. Pin an exact version in Package.resolved and read the changelog before moving.

The licence is the least clear part. GitHub reports the licence as NOASSERTION, meaning the platform could not map the LICENSE file to a recognised SPDX identifier. The README links to a License section but the repository metadata does not state which terms apply. Read the LICENSE file in the repository root yourself before shipping anything, and if the terms matter to your organisation, get them reviewed. This is not legal advice, and the NOASSERTION label is a reason to look, not a conclusion.

Editorial conclusion

Adopt the MCP Swift SDK if you are building a Swift 6.0+ application or service that needs to speak MCP as a client or expose tools, resources and prompts as a server, and you are willing to track a pre-1.0 API that moved from 0.11.0 to 0.12.1 between February and May 2026. Do not adopt it if your deployment target is not covered by the Platform Availability section, or if you need a stable API surface you will not have to revisit on each minor release. Before committing, read the Platform Availability and Transports sections in the README against your own deployment targets, check whether the transport you need is listed there, and confirm the licence terms from the LICENSE file and the GitHub metadata, since the repository is published under a NOASSERTION licence identifier rather than a recognised SPDX name.

Frequently asked questions

Official sources

1. Issues
2. modelcontextprotocol/swift-sdk on GitHub
3. README
4. Releases