LocalLM Lab

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.

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. Two open-source reference apps in the SDK repo show the same code in practice: plate-today, a single-window daily-summary app pulling from Calendar, Reminders, and the Todoist MCP server; and components-demo, which exercises the MCP server picker end to end against a real, no-auth MCP server — and can double as a handy way to explore an unknown MCP server yourself.

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, both reference apps, and the full developer guide are in the LocalLM GitHub repo:

Both example apps require an explicit SDK version to build:

LOCALLM_SDK_VERSION=0.7.0 swift build

Contact

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