Mac menu bar automation for local workflows
Automate the repeatable state changes, not the entire day. Shortcuts, URL schemes, display presets, and local utility checks work best when they remove one small interruption you already know is real.
The practical answer: start with one Mac menu bar automation that changes state you already repeat. A Work display preset, a Night brightness command, a local hash check, or one utility launcher is a good candidate. A giant personal operating system made of fragile shortcuts is not.
Apple Shortcuts can run from URL schemes, keyboard shortcuts, Quick Actions, the Services menu, and the menu bar. That makes it useful as glue. It does not mean every tiny Mac task should become a workflow. The menu bar should stay a place for fast controls, not a second settings app.
Disclosure: I build TeenyApps, including TeenyTool and TeenyDisplay. My bias is toward small native Mac utilities. The advice below is still conservative: automate only the pieces that survive a normal workweek.
Quick decision table
| Automation candidate | Use it when... | Keep it manual when... |
|---|---|---|
| Display preset | You switch between Work, Night, Presentation, or another-computer desk states. | The desk stays in one setup all day. |
| Brightness URL command | Room light changes often and your external monitor ignores normal keys. | You adjust brightness once and leave it alone. |
| Local utility launcher | You repeatedly open JSON, URL, JWT, hash, Base64, or text tools while another app is active. | You use the tool once a month. |
| Local text check | The copied string came from a ticket, token, API response, unreleased UI, or internal URL. | The data is public or the job depends on live web data. |
| Full shortcut workflow | Several tiny steps repeat in the same order and failures are easy to spot. | You are still experimenting with the steps. |
Start with one repeated state change
The best automation target is boring. You already do it. You know the exact before and after state. You can tell when it worked. You would rather press one command than think about it again.
External monitor state is a strong example. A desk can have real modes: Work, Night, Presentation, Focus, or another computer on the same monitor. If those modes change brightness, contrast, input source, volume, resolution, or refresh rate, a named preset is easier to trust than several manual slider moves.
Small utility checks are the other strong example. If you often copy private text and need to hash it, decode it, format it, diff it, or convert it before sharing, a local tool belongs close by. The automation may be as simple as opening the toolbox or favoriting the tool. That still counts if it removes the tab hunt.
Where URL schemes fit
Apple's Shortcuts guide says URL schemes can run shortcuts from outside Shortcuts, including from another app, a browser, or the command line. That is the right mental model: a URL scheme is an entry point.
For display control, TeenyDisplay exposes a teenydisplay:// URL scheme. Its source supports commands for brightness, contrast, volume, input, power, presets, and display info. The app checks license access before mutating display state, while the read-only info command can run without full access.
A focused URL command is useful because it can be launched by Shortcuts, a launcher, a script that opens URLs, or any other tool that can hand macOS a URL. It is less useful when you need logging, branching, retries, or a complex decision tree. Then Shortcuts or a real script should own the logic, and the URL command should stay one step inside it.
Display automation that earns a shortcut
A display automation is worth keeping when it changes the desk in a way you can name. "Night" is a good preset. "Brightness minus ten percent on every external display" is a good command. "Tweak a slider because the monitor feels a little off" should probably stay manual until it becomes a pattern.
The Monday TeenyDisplay spoke goes deeper: Automate external monitor brightness with Mac Shortcuts. It covers URL examples such as teenydisplay://brightness?display=all&delta=-10 and teenydisplay://preset?name=Work, plus the limits around DDC support, display targets, and license state.
The blunt rule: automate the desk states that interrupt real work. Do not automate every knob just because the URL scheme can reach it.
Local tools are the pre-flight checks
Automation gets risky when it copies data from one place to another without a human noticing what moved. That is why local utility checks matter before sharing, filing, or pasting private snippets into another system.
TeenyTool is the toolbox side of this cluster. Its homepage lists 75+ tools across text, math, images, colors, developer work, files and PDF, clock, and random utilities. Its source includes JSON Formatter, URL Codec, Base64 Codec, JWT Decoder, JSON Diff, Regex Tester, Hash Generator, UUID Generator, Unix Timestamp Converter, and other small checks that often sit around copied developer text.
The Monday TeenyTool spoke is SHA-256 hash generator for Mac. It is deliberately narrow: hash and verify copied text locally, understand what MD5, SHA-1, SHA-256, SHA-512, and CRC32 are for, and know when a file checksum belongs in Terminal instead.
What not to automate
Do not automate a task you have not stabilized. If you are still changing the steps, keep them visible. Good automation starts after the workflow is boring, not before.
Do not use URL commands for secrets unless the app and the command are designed for that data. URLs can end up in shell history, launcher history, browser history, or logs depending on how you run them. For private text, the safer move is usually to open a local tool and paste deliberately.
Do not fight macOS for system-owned behavior. Apple's keyboard shortcuts, function keys, Displays settings, Services, and Shortcuts all exist for a reason. Menu bar apps should fill the narrow gaps: external monitor controls, local scratch utilities, small state changes, and cross-app controls that Apple does not expose cleanly.
Common questions
What should I automate first on a Mac menu bar setup?
Automate the repeated state change first: a display preset, brightness change, or local utility check that happens several times per week while another app is active.
Are URL schemes enough for Mac automation?
They are enough for focused app commands that can be represented as a URL, such as running a shortcut or sending a display command. They are not a replacement for full scripting when you need branching, logs, or error handling.
Should private utility checks run online?
No. If the input came from a ticket, token, customer record, unreleased UI, API response, or internal URL, keep the check local unless the job genuinely requires live web data.
Sources checked
- TeenyTool claims were checked against the TeenyTool homepage and local source files for the tool catalog, Hash Generator, favorites, shortcuts, and network exceptions.
- TeenyDisplay claims were checked against the TeenyDisplay homepage and local source files for URL commands, presets, brightness controls, shortcut settings, and license-gated commands.
- Apple Support: Run a shortcut using a URL scheme on Mac.
- Apple Support: Run a shortcut while working on your Mac.
- Apple Support: Intro to URL schemes in Shortcuts on Mac.
Automate the small jobs that keep repeating.
TeenyApps are native Mac menu bar utilities for local tools, display controls, colors, screenshots, clipboard history, mic mute, sound, stats, shelves, and screen time.