u/AdventurousKeys

Small but useful thing that landed in the latest LocalLM Lab release (0.6.0 if you want to know) that is worth sharing here: the MCP Servers panel can now export a connected server's entire tool list as plain text: tool names, per-tool token cost estimates, current enabled/disabled state and full descriptions.

Ran it against Linear (https://mcp.linear.app/mcp) and it turned up something I didn't expect: a lot of the real usage constraints for that server aren't in the schema at all, they're written as freeform instructions inside the tool descriptions. create_attachment embeds a full base64/SHA-256 checksum-verification script (shell and PowerShell versions) with an explicit warning not to print base64 content and copy it back into the tool call, since that's an easy way to corrupt it. prepare_attachment_upload has its own sequencing rules: don't batch multiple prepare calls before starting the uploads, because earlier signed URLs can expire while later ones are still being prepared, and the signed URL itself is only valid for 60 seconds. None of that shows up if you're only looking at parameter types — it only surfaces if something actually reads the description text, which a lot of tool-calling setups truncate or never expose to a human at all.

Excerpt from the export (Linear, create_attachment / prepare_attachment_upload / create_attachment_from_upload):

- [ ] prepare_attachment_upload (~489 tokens)
    Prepare a direct Linear file upload for an existing issue.

Workflow:
1. Call this tool with issue, filename, contentType, and size.
2. Upload raw bytes with PUT to uploadRequest.url outside MCP.
3. All headers in uploadRequest.headers are part of the signed request, so send them verbatim.
4. After PUT succeeds, call create_attachment_from_upload with assetUrl to link it to the issue.

Omitting or modifying any signed header, including casing, will return HTTP 403.
The signed URL must be used within 60 seconds or it will expire.

Upload sequencing:
Do not batch multiple prepare_attachment_upload calls before starting the PUTs
because earlier signed URLs can expire while later files are prepared.

- [ ] create_attachment_from_upload (~245 tokens)
    Link an already-uploaded Linear assetUrl to an existing issue as an attachment.
    This tool does not upload file content. It only creates the Linear attachment row.

- [ ] create_attachment (~663 tokens)
    Deprecated fallback for tiny files only. Accepts base64 file content, verifies
    SHA-256 checksum, and uploads it through the MCP worker.

    CRITICAL: Do not print base64Content and then copy it into this tool call.
    Opaque base64 copied through model-visible text is easy to corrupt.
    Generate base64Content mechanically from the source bytes and pass it through
    a programmatic argument construction path whenever available.

Worth being upfront about one thing here: create_attachment is a bad candidate for actually letting a model generate its own arguments and the description says so directly. It's telling implementers not to let an LLM produce or handle the base64/checksum values at all and to compute them in your own code instead. That tracks: getting a base64 encoding and a SHA-256 hash exactly right via token generation is exactly the kind of precise, deterministic task a small on-device model is bad at, and a real file's base64 blob would blow past the ~4096-token budget (on the Mac's local AI) on its own anyway. prepare_attachment_upload doesn't have that problem (just small metadata fields), but the actual PUT happens outside MCP per the workflow above, so no version of this attachment flow is something the model can drive end to end regardless of size.

Why this is relevant to the rest of the release: localai-cli, the new CLI toolkit that shipped alongside this, lets you call any of these tools programmatically from your own Swift or Python code ->{"server": "https://mcp.linear.app/mcp", "tool": "create_attachment_from_upload"} is a more realistic example, since it's just an issue ID and a URL, nothing to compute. Once you've got the export in front of you telling you exactly what a tool expects and warns against, it's a decent way to sanity-check that description against real model behavior before building against it for real.

Tool export + CLI writeup: thisbrain.ai/locallm/cli.html

MCP servers page: thisbrain.ai/locallm/mcp-servers.html

This one's a developer-facing release, but I think it's worth posting here because of what it enables: v0.6 of LocalLM Lab includes a toolkit that give developers a way to plug the on-device Apple Intelligence model directly into their own Mac apps.

Some background: LocalLM Lab already let you experiment with the on-device model directly (Prompt Playground) and call it like a cloud AI API from your own scripts (API Lab).

v0.6 adds a third way in, built specifically for people writing real native apps whether a menu bar tool, a game or a utility. The app can talk to your on-device Apple Intelligence model without running a server or needing an internet connection, and it respects whatever permissions (Calendar, Reminders, connected services, etc.) you've already granted through LocalLM Lab itself.

To be clear about where this stands: this is still an experimentation tool for developers and not a finished platform. LocalLM Lab needs to be running in the background for it to work, so it's not something apps can quietly bundle and ship yet. What it does is lower the bar for developers who want to try building something real on top of the Mac's on-device AI.

A concrete example, so this isn't just abstract: there's now a sample script called "Plate Today" — it checks your Calendar, Reminders, and Todoist tasks for the day and asks your on-device Apple Intelligence model to give you a plain-English summary of what's on your plate. It's a few dozen lines of code, and it only works with permissions you've already granted through LocalLM Lab itself. It can't quietly reach further than that. Small example, but it's the kind of thing that's now realistic for any developer to build.

If you're technical and curious: thisbrain.ai/locallm/cli.html.

Continuing to build on LocalLM Lab, the tool that I posted about here a couple weeks ago.

A couple of things have landed since. MCP client support shipped in v0.4.0. LocalLM Lab is now a real MCP client and can connect to real MCP servers now: GitHub, Linear, Notion, Slack, and others.

As of v0.6.0, there's a proper way to reach the on-device model straight from your own Swift or Python code, not just through the app's UI or its HTTP API.

It's called localai-cli, a small subprocess binary. Your app spawns it, writes one JSON request to stdin, reads one JSON response from stdout. That's the whole interface... no HTTP server, no port to manage, no client library to link against. Feels like the right shape for a native app: a menu bar tool or a game doesn't want to run a localhost server just to ask a question.

The part I think is actually interesting for this crowd: it's config-scoped. It reads the same localai-config.json that the app's own Local AI Settings / MCP Servers panels write, so whatever connectors and MCP tools your user already turned on in the app's UI are exactly what your code is allowed to ask for. Request something outside that set and you get an error back before the model is even invoked. Omit the field entirely and nothing is granted at all. That's deliberate and not an oversight.

To be upfront: this is still an experimentation tool, not a shipping SDK. LocalLM Lab has to actually be running for localai-cli calls to work (they relay through its background process), and I'm not pretending the permission/auth model here is the right shape for a real distributed app yet. What this does give you today is the fastest way to wire your own code up to the on-device model, including whatever connectors and MCP tools you've already set up. All this without writing an HTTP server or reimplementing any of that plumbing yourself.

There's a fuller example on the page beyond the two quickstarts too. "Plate Today" is a script that pulls Calendar, Reminders, and Todoist (the last one via an MCP tool call, not a connector) into a single request and asks the model for a one-paragraph summary of your day. You'll want to set up a free account with Todoist and some todos...!

The part I'd actually call out for this crowd: before it ever invokes localai-cli, it reads localai-config.json itself and checks all four sources (three connectors + the Todoist MCP tool) are actually enabled, prints a checklist, and exits without touching the model if anything's missing. So a misconfigured permission will fail fast with a "go flip this toggle" message instead of burning a model call on a request that was always going to error.

Interface + Swift and Python examples: thisbrain.ai/locallm/cli.html MCP writeup from v0.4, if you missed it: thisbrain.ai/locallm/mcp-servers.html

PS: unrelated to the CLI, but since this crowd will notice: Prompt Playground's UI has moved from a browser window to native SwiftUI in this release.

A question to folks who are building apps around Apple's Foundation Models: how are you testing the prompts and validating the results?

I was doing a bunch of tweak->build->test cycles where the only tweaks were adjusting the system & user prompts. Since the local AI model is so small (just 4096 context budget), it didn't make sense to develop the prompts using your usual OpenAI/Anthropic models and expect the same behavior.

I developed LocalLM Lab to experiment with the local LLM on the Apple Silicon Macs (mine is an older M3 MBA with the lateset macOS26). When I added Connector support to LocalLM Lab (mostly so that it can get the time of day), I realized that the local LLM isn't great at reasoning out the days of the week. If you have tried out the latest 0.3.0 version of LocalLM Lab, you know that you can connect the local LLM to macOS' Reminders and Calendar apps. On Prompt Playground, if you type in "Let's have Chinese takeout at 7pm on Wednesday" (assuming that you are doing this test on Sunday), the model will actually setup a Chinese takeout event at 7pm. But that event will not necessarily end up on a Wednesday...! I have seen anything from Chinese takeout on Monday, Tuesday or even on Thursday! I leave it up to y'all to figure out how to frame the prompts (system + user) to get it right!