Two tools is the entire surface, and the second is why the first works: the tips call retrieves a runnable script for the app in question before anything executes. After the permission prompts are out of the way, 'rename these files and open the folder' is one call rather than a script you write, save and debug.
A local server with two tools: one runs AppleScript or JXA on the machine, the other searches a bundled knowledge base of runnable automation scripts covering system tasks, files, browsers, terminals, productivity apps, developer tools and UI automation.
- AppleScript or JXA run from inline script content, a script file on disk, or a knowledge-base entry by its runnable id
- Arguments passed in as named input data or positional values, the output format chosen, and a per-call timeout set
- The script knowledge base searched by keyword or listed by category, so a Finder or Safari task starts from a known-good script rather than one composed from memory
- Your own scripts layered over the bundled ones from ~/.macos-automator/knowledge_base, or another path through LOCAL_KB_PATH — additions and overrides without touching the package
A Mac and Node.js 24 or newer; no account and no key. The permissions are the part that stops people: whatever launches the server — Terminal, your editor, the desktop client — owns the macOS privacy grants, so it needs Automation access to control Finder, Safari or Mail and Accessibility access for clicks, keystrokes and menus through System Events. macOS prompts on first use per application, and the server cannot grant any of it for you. Scripts run with the privileges of that host process. MIT licensed.
One command — npx -y --package @steipete/macos-automator-mcp macos-automator-mcp