Inspect an application dictionary

Scriptable Mac apps publish a scripting dictionary: the commands, classes, and properties they deliberately expose to AppleScript. A dictionary is the application’s automation contract. Before scripting any app, read its contract.

Open Script Editor and choose File → Open Dictionary. Select an application you use, then find one command and the object it accepts. The dictionary browser groups terminology into suites, each containing commands (the verbs) and classes (the nouns, with their properties).

Finder exposes files and folders. Other apps may expose documents, windows, tabs, or no useful commands at all. An empty or trivial dictionary is an answer too: it tells you AppleScript is the wrong tool for that app before you spend an evening finding out the hard way.

You can also dump a dictionary from the terminal:

sdef /System/Library/CoreServices/Finder.app | head -30

sdef prints the raw XML that Script Editor renders. It is useful when you want to search a large dictionary with grep instead of scrolling.

Once you find a promising property, test it read-only from Script Editor:

tell application "Finder" to get name of startup disk

The result pane shows "Macintosh HD", or whatever your disk is called. A small read like this verifies three things at once: the terminology is right, the app responds, and you have permission to talk to it.

Do not guess terminology from the interface label. The menu may say one thing while the dictionary names the object something else entirely, and AppleScript rejects the words the UI taught you with an unhelpful error. Use the dictionary and test read-only properties before sending commands that change documents.

The realistic failure: a property exists in the dictionary but the app implements it badly. Dictionaries are contracts, and some apps honor theirs loosely, especially older ones. When a documented command misbehaves, test it in isolation in Script Editor before assuming the bug is in your script.