SDK

The first MCP client built for Apple's on-device model — link it into your own native Mac app

LocalLM Lab itself is built on a Swift SDK, LocalLMLabSDKCore, and you can build on the same thing. Link it into your own macOS app and it gives you instant Calendar, Reminders, Contacts, and Location access — no EventKit wrappers to write — plus a real MCP client: tool discovery, all three OAuth flows, Keychain-backed token storage. No MCP or OAuth stack to build yourself.

Two ways to get from there to a model your app can actually call tools with: drop in a ready-made Tool for each connector — GetUpcomingEventsTool, SearchContactsTool, and the rest, plus one for any MCP server tool built at runtime straight from its own schema — or write your own adapter against the same underlying connector calls for full control over names, schemas, and descriptions. Both ship in Core; neither is the "real" one. See the full connector reference for what each one can and can't do.

Why local AI + MCP together is the point

Every MCP client in wide use today assumes a cloud model on the other end of the tool call — Claude, GPT, Gemini — reachable over the network, with the whole tool-calling loop running on someone else's servers. This SDK's MCP client is wired directly to Apple's on-device FoundationModels model instead: the model deciding which tool to call, the request going out to a real MCP server (Slack, Todoist, GitHub, Notion, Linear, and others), and the result coming back all happen with the model itself running locally, on the Mac's own Neural Engine.

Nothing about that decision — the prompt, the tool selection, the intermediate reasoning — has to leave the device and reach an external model provider just so your app can be AI-powered. That's a genuinely different privacy and security posture than any cloud-model MCP client can offer, and a different cost story too: no per-token bill for the model itself, so whatever your MCP servers charge (often nothing) is the only external cost your users take on.

Proven under App Sandbox, not assumed

Sandboxing an app breaks all sorts of things silently — network calls, background permissions, subprocess spawning. Rather than assume the SDK would just work under sandbox, it was built into a sandboxed test app, hit real breakage (a missing network entitlement that silently killed weather lookups and MCP connections), fixed, and re-verified: Calendar, Reminders, and the full MCP+OAuth+Keychain flow all confirmed working under sandbox, with real system permission prompts — not just "should work in theory." There's also a working path to a Mac App Store submission: an Apple Distribution signing + provisioning profile pipeline that produces a correctly signed .pkg, with a verified signature chain up to Apple's own root CA.

Real UI, not just an API

Components ships ready-to-drop-in SwiftUI: an "add an MCP server" screen supporting all three auth types (no auth, personal access token, OAuth), tool and resource enable/disable controls, an OAuth-waiting view for the browser round trip, and a one-click summary export of what a connected server actually offers. You don't have to build MCP UI from scratch to give users a way to manage what your app is allowed to reach.

Dogfooded in a real, shipping app

LocalLM Lab doesn't keep a private copy of this code around — it depends on the SDK directly. When this page says Calendar or MCP access "works," it means it works in a real app real users run, not just in a sample project.

Start from working code

Five open-source reference apps ship with the SDK — use the closest one as a starting reference rather than writing from scratch. Each has a README with copy-paste setup.

Example	Start here if you want…
`repo-qa`	to connect to an MCP server you don't control — the smallest example, a CLI, no signing or permissions. Builds a `Tool` from a live server's own schema.
`plate-today` / `-tools`	connectors (Calendar, Reminders) plus an OAuth-gated MCP server (Todoist) in a signed SwiftUI app. The two are the same app on Path B (hand-written adapters) and Path A (Core's ready-made `Tool`s) — diff them.
`workspace-buddy`	to give the model scoped access to a folder of files under App Sandbox — `WorkspaceTools` plus the security-scoped-bookmark pattern.
`components-demo`	to drop in the prebuilt SwiftUI MCP-server management UI instead of wiring one connection yourself.

annotated-examples.md walks every one line by line, SDK touchpoints marked inline.

Licensed to actually be used commercially

Apache 2.0 — chosen specifically for its patent grant, which matters if your legal team has to sign off on embedding a third-party SDK into a commercial product. Versioned binary releases are published on GitHub with checksums, the same way you'd expect to pull in any other serious SDK dependency.

Get it

The SDK, the reference apps, and the full developer guide are in the LocalLM GitHub repo:

docs/sdk-guide.md — linking Core, entitlements, all three MCP auth types, Keychain storage, App Sandbox/Mac App Store signing, ready-made vs. hand-written tool-calling (§7a), and a full flat API reference.
examples/ — the five reference apps in the table above (docs/annotated-examples.md walks each one line by line).
Components — the reusable SwiftUI layer itself.

Every example requires an explicit SDK version to build — the latest release, 0.8.0, works for all of them:

LOCALLM_SDK_VERSION=0.8.0 swift build

plate-today-tools, repo-qa, and workspace-buddy specifically need 0.8.0 or later — each depends on Core additions (ready-made connector Tools, MCPTool, and WorkspaceAccess/WorkspaceTools respectively) that shipped in that release. Building any of the three against 0.7.0/0.7.1 fails to compile with a clear, specific error rather than running with reduced functionality.

Contact

Questions, or building something with this? Contact neuron@thisbrain.ai or join our Discord.