Adding MCP and connector support to your own Foundation Models apps

Question

Created 2w

Replies 2

Boosts 0

Participants 1

Circling back on the LocalLM Lab arc. With v0.7, we've moved from prompt experimentation into real app development on Apple's Foundation Models local AI. The LocalLM Lab SDK lets you build that same on-device model and MCP client this thread has covered directly into your own app, with real tool and data access (Slack, Todoist, GitHub, Notion, Linear, plus Calendar, Reminders, Contacts and Location). And you can ship your app including through the Mac App Store.

This is a big improvement over version 0.6, where the localai-cli toolkit needed LocalLM Lab installed and running. On the other hand, the SDK (LocalLMLabSDKCore) doesn't relay through anything; it links FoundationModels and a real MCP client directly into your own binary and is totally self-contained.

The example included in the SDK, Plate Today, has actually been built into a sandboxed test app and verified working, with a signed path to a Mac App Store .pkg (Apple Distribution signing + provisioning profile pipeline). That's "verified signable and sandbox-compatible," to be precise.

Entitlements (from personal experience: always a complicated topic): com.apple.security.app-sandbox + com.apple.security.network.client for the app itself, plus the standard personal-information entitlements per connector used (com.apple.security.personal-information.calendars, .addressbook, .location) and matching NS*UsageDescription strings in Info.plist. The one worth flagging specifically: the network entitlement is easy to miss and fails silently rather than throwing. Without it, MCP connections and Weather calls just hang with no error surfaced.

OAuth handling requires the app delegate callback (application(_:open:)), not SwiftUI's .onOpenURL. Worth knowing before wiring it up if you're SwiftUI-only.

Full entitlements list + SDK guide: https://github.com/ancientcomputing/locallm/blob/main/docs/sdk-guide.md Feature page: thisbrain.ai/locallm/sdk.html

I hope the availability of the SDK (free, Apache 2.0 license) will give folks further incentive to explore local AI-enabled applications on the Mac. What else would you want to do that the SDK doesn't currently support? File picker? Calendar/Reminders/Contacts edits & writes?

Answer 1

svgeek OP

1w

Quick 0.8 update on this. The SDK now ships ready-made Tool wrappers for every connector (Calendar, Reminders, Contacts, Location etc) and new this release, Filesystem via WorkspaceTools. Previously, you would have to write your own adapters (which remains fully supported alongside the new tools).

We ended up going the Tool wrapper route because Apple's local AI (at the macOS 26 level) wasn't reliable at mapping (to give an example) a human-readable Calendar event (Lunch on August 25) to the event ID that the connector used to require to perform any action on that event.

Some of you will wonder: isn't that Apple's Tool protocol reimplemented? Well, it's Apple's Tool protocol used the way it's meant to be, with the annoying parts done for you. That means handling connector-level gotchas like the identifier problem above so you don't have to rediscover them yourselves, plus one piece Apple doesn't provide at all: MCPTool, which builds a Tool at runtime straight from an MCP server's JSON Schema. FoundationModels has zero MCP support of its own. Short version: we're not replicating Apple's Tools, we're using them, and taking care of the parts that were genuinely annoying to get right.

Filesystem access itself (the picker, security-scoped bookmarks) is still deliberately host-app territory, not part of the SDK. Everything downstream of that (once your app has a resolved folder URL) is where WorkspaceAccess/WorkspaceTools come in. This includes an async-aware access pattern (withFolderAccessAsync) that is needed since a model session can invoke several file tools across one respond(to:) call. The new source-code-included example (workspace-buddy) shows it in context. Maybe it's your route to building a coding agent using the local AI ...!

Answer 2

svgeek OP

3d

Update on LocalLM Lab: 1.0.0-beta.1 adds a model layer to the SDK. This means one API across Apple's on-device FoundationModels model, Claude, and a locally-run open-weight model via MLX (a separate runtime, LocalLMLabSDKInference), with routing and model residency (which model stays warm, how many at once) owned by the SDK rather than something every app has to build itself.

This is entirely SDK-side, not a FoundationModels API change. SystemModelProvider still wraps SystemLanguageModel under the hood the same way it always has. A fourth provider, PCCModelProvider (Apple's Private Cloud Compute), ships in this release but isn't functional yet in 1.0.0-beta.1. Check out https://developer.apple.com/private-cloud-compute/ for more info on this.

Requires macOS 27 beta, Apple Intelligence enabled, Xcode 27 beta for SDK development.

SDK guide: https://github.com/ancientcomputing/locallm/blob/main/docs/sdk-guide.md

Feature page: thisbrain.ai/locallm/1.0.0-beta