I updated the Drafts MCP Server project to include a command-line interface that wraps the same functionality provided by the MCP.
Once installed and linked (see instructions in README, you will have a new drafts terminal command that can update, create, query drafts just like the MCP. Here’s the output of drafts help describing the supported commands:
Usage: drafts [options] [command]
CLI for interacting with the macOS Drafts app
Options:
-V, --version output the version number
--json Output raw JSON instead of formatted tables
-h, --help display help for command
Commands:
workspace Workspace commands
tag Tag commands
list [options] List drafts with optional filters
get <uuid> Get a draft by UUID
current Get the current draft open in Drafts
create [options] <content> Create a new draft
update <uuid> <content> Update a draft's content
open <uuid> Open a draft in the Drafts editor
archive <uuid> Archive a draft
inbox <uuid> Move a draft to inbox
trash <uuid> Move a draft to trash
flag [options] <uuid> Flag or unflag a draft
add-tags <uuid> <tags...> Add tags to a draft
search <query> Search drafts by content
action Action commands
help [command] display help for command
Feedback is welcome, this is not extensively tested, and may need some additional documentation, but should be useful for some. A couple of examples of commands:
// create a new draft
drafts create --tag work --flagged "Hello World"
// list tags
drafts tag list
// run action
drafts action run <draft-uuid> <name-of-action>
This is great to see—I always appreciate all your great work, Greg!
One note: list operations on large libraries are quite slow, as is likely anything proportional to library size. I ran into similar issues previously with the 3rd party drafts-applescript-cli and found that it was possible to get many orders of magnitude speedup by going directly to SQLite for read operations instead of using AppleScript events. Have you considered this?
I realize it potentially complicates the code and creates opportunities for divergence in implementation, but it’s essentially impossible to list my current library using (I let it run for 30 minutes before giving up), while it takes a fraction of a second with raw SQLite + halfway reasonable code to format the output as JSON or otherwise.
You are welcome to code something up yourself. That will not be part of an official release, as I don’t support working directly with the SQLite DB and you would be missing out on the logic layer that makes up some of the content of a draft object.
That said, are you actually trying to load your whole library with the MCP? It’s not the most performant by any means but I have a large library with many thousands of drafts, and generally don’t find the performance of the MCP to be problematic for scoped queries, like returning items with a specific tag, etc.
Of course, no pressure on whatever design you think makes sense from your perspective keeping everything maintainable! I understand the tradeoff.
And no, I don’t have huge queries in the MCP (I’m not actually using the MCP), but I was just playing manually with the CLI and considering potential automations. The performance wasn’t surprising given past experience trying to do anything at nontrivial scale through AppleScript interfaces, but it was definitely too slow for things which returned results proportional to the size of my library to seem feasible. I’m away from my personal Mac at the moment, but it was literally like 4 orders of magnitude slower than a corresponding SQLite query if I recall correctly. My library may be an outlier (~9k in inbox, ~15k in archive).