My favourite MCPs: macos-automator

Some software you just can't reach. Well, macos-automator gets it.

Not sure what an MCP server is or how it’s used? Check out my explainer here.

macos-automator runs AppleScript on your Mac on request. AppleScript is the old, creaky language Apple built in the nineties so applications could drive each other, and because it’s been around that long, a great deal of Mac software can be controlled with it even when it offers developers nothing else at all.

So this is the tool that turns “here’s how you’d do that on a Mac” into “done”. Most assistants can tell you which menu to click. This one clicks it. It also ships a library of ready-made scripts, which matters more than it sounds.

What I use it for are the jobs nobody will ever build an integration for. Pulling today’s calendar into my morning briefing as plain text. Reading unread mail in an app that speaks only AppleScript. Exporting from software old enough that its export button doesn’t do what you want. These tasks stay manual forever precisely because no vendor has any reason to automate them.

Then there was the day that taught me how this actually fails.

Every attempt to read mail through AppleScript hung. No error, no refusal — nothing, until it timed out with a number meaning “the event took too long”. My first instinct was that the mail app had wedged, so I killed it and restarted it, killed stray script processes, cleared a system dialog that had been sitting open since the previous Sunday, and turned off a sandbox. None of it made any difference.

What settled it was checking whether other applications behaved the same way. Asking Finder for something hung identically. So did the system’s own scripting component. Two unrelated parent processes, same hang. That isn’t a wedged app; that’s macOS silently refusing automation because the permission was never granted. Reading the mail folder directly came back “operation not permitted”, which is the same story told from the other end.

The clincher came later. The identical script ran perfectly in a normal desktop session. Same code, same machine, different kind of session. When the same instructions succeed in one context and hang in another, stop debugging the instructions.

Making it repeatable

The one-off ask is usually mundane, which is the point:

Pull today’s calendar events into plain text for the morning brief.

The standing version lives in a skill — a text file of instructions the assistant reads when the job comes up, written in plain English:

When running local scripts on this Mac:
- If a script hangs with no error, suspect permissions before the
  app. Try a second application; if that hangs too, macOS is
  refusing automation.
- Never assume the frontmost window. Target the app and the
  document by name.
- Assign a date to a variable before formatting it. Formatting
  inside a longer expression returns something that won't
  convert.
- If it works in my desktop session but not unattended, say so
  rather than retrying.
- Check the script library before telling me something isn't
  possible.

Every line there is a mistake already made, and the last one is mine at its most embarrassing. I’d assumed there was no browser automation available in my setup and said so out loud. Four runnable scripts were sitting inside this tool the whole time. They happened to be blocked by the permission problem above — but “blocked” and “doesn’t exist” are very different sentences, and I said the wrong one without looking.

The third rule looks like trivia and isn’t. AppleScript dates are genuinely awkward: format one inside a longer expression and you get back a wrapped value that refuses to become a string, with an error number that explains nothing. Assign it first, build the string from year, month and day, move on with your life.

The project is open source and installs in a line. Grant Accessibility, Automation and Full Disk Access to whatever’s running the scripts before you rely on it, and test one small script deliberately.

My calendar now arrives as text every morning, from an app that has no API and never will.