The command line and MCP

The command line

Install it from Settings, Developers. It is the same binary as the app, symlinked rather than copied, so it never falls behind the app it came from.

listen help prints the whole thing. The shape of it:

listen record [--seconds N]       capture until stopped, or for N seconds
listen transcribe <file|id>       transcribe a file, or a whole recording
listen list [--limit N] [--tag T] recordings as a table
listen show <id>                  metadata and transcript
listen export <id> [--format]     write a transcript out
listen title <id> [<text>]        what one recording is called

listen label <id> <speaker> ...   name, merge, discard or move a speaker
listen edit <id> <old> <new>      correct one sentence of a transcript
listen people [<name>]            who is in the library, or where one person is
listen rename / merge / unname    one person, across every recording
listen forget <name>              strip their voiceprints from every bank, on
                                  every Mac. Transcripts are untouched.
listen me [<name> | --clear]      what the microphone track is called on screen
listen enroll [<id>...]           re-derive voiceprints for named speakers
listen voices <id> [--apply]      who the bank thinks each unnamed speaker is
listen calibrate                  voiceprint threshold report

listen dictate <file>             run the dictation pipeline over a file
listen polish [text|-]            polish and correct text, as a dictation would
listen dictations [--limit N]     what you have dictated

listen ask [<question>]           put a question to Claude Code, Codex or an
                                  endpoint, all reading through `listen mcp`
listen provider <sub>             the OpenAI-compatible backends
listen mcp                        stdio MCP server

listen notes <sub>                the notes, one or many recordings each
listen tags <sub>                 what the recordings are about, in your words
listen dictionary <sub>           your own terms and corrections
listen calendar <sub>             the calendars on this Mac, and what they name
listen contacts <sub>             which address belongs to which person

listen sync <sub>                 status, inspect, trash, key, enable
listen audio [<id>] [--build]     what audio exists and which devices keep it
listen backup [--now]             the local copies of the library
listen activity [--limit N]       what has touched the library. Ids, never
                                  content.
listen import <path>              bring in a meet_transcriptions library
listen sources                    what meeting detection sees, during a call
listen changelog [<version>]      what changed, from the notes in this copy

listen calendar match <id> is the one worth knowing about. Naming happens silently, so it prints every meeting that could have been the one, how many minutes each is away, and which one won:

$ listen calendar match 2026-08-03-160054-D478
Ryan Mitchell - Meridian
started 3 Aug 2026 at 16:00

→   -1m  Emily Carter and Ryan Mitchell
    Google / Home · 16:00 · 2 invited
    https://us02web.zoom.us/j/00000000000
    · Emily Carter <emily.carter@example.com>  [you]
    · Ryan Mitchell <ryan.mitchell@example.org>  [organizer]

listen calendar backfill does the same over your whole library and changes nothing without --apply.

listen calendar next prints what the library's own "Up next" section is showing, and then every meeting nearby that it left out with the reason:

$ listen calendar next
up next:
  in 12 min      Standup  (Ryan Mitchell, Emily Chen)  [link]
  15:30          Design review  (Sam Okafor)

not listed:
  now            Reading time  [nobody else invited]
  Tomorrow 00:00 Kate's birthday  [all-day]

listen calendar next --prompt prints the question the Prepare button sends, so the window and the command are provably asking the same thing:

listen ask "$(listen calendar next --prompt)"

listen transcribe some.wav needs no permissions at all, which makes it the fastest way to tell a model problem apart from a recording problem. It prints what the model actually said: the dictionary applies to what goes into the library and nothing else, so this command cannot be quietly editing its own output.

listen dictionary list            every entry, and what each has changed
listen dictionary add <term>      a word to spell right, matched by sound
listen dictionary add <a> <b>     an exact replacement
listen dictionary test "<line>"   what your rules would do to a sentence
listen dictionary import <path>   merge a dictionary file in
listen dictionary export [<path>]

listen notes list [<id>]          every note, or those about one recording
listen notes read <slug>          one note, body on stdout
listen notes write "<title>" --recording <id>    add one
listen notes delete <slug>        remove one

listen tags                       every tag, and how many recordings
listen tags add <id> "job hunt"   tag a recording
listen tags remove <id> <tag>     take one off
listen tags rename <tag> <new>    rename it in every recording
listen tags delete <tag>          take it off everything
listen list --tag "job hunt"      only those. Repeat it; several mean all.

A tag is free text, so quote one with a space in it. It lives on the recording, so deleting a meeting takes its tags with it and a tag nothing carries stops existing: there is no separate list to keep tidy. That is the opposite of a note, which lives in the library and can outlive any one meeting, and both are on purpose.

listen ask                        what is set up, and nothing else
listen ask "<question>"           through whichever backend is configured
listen ask --to <url> "<q>"       one run against a URL, changing no preference
listen ask --write "<q>"          let it write notes, tags, dictionary rules
                                  and names
listen ask --print-request        the POST body it would send, minus the key
listen provider list              the endpoints this Mac knows about
listen provider add <id>          one of the twelve, or a URL of your own

--print-request and --print-command are the honest way to find out what an Ask actually sends before it sends it. Neither runs anything.

listen sync status                what this build can reach, and as whom
listen sync inspect               what is in the container, by zone
listen sync inspect --recording <id>
                                  one recording across every zone: who holds
                                  the audio, and what is in flight
listen sync trash                 deletions received in the last fortnight
listen sync key [--show]          the key that seals what iCloud holds
listen sync enable [--on|--off]   sync this Mac's real library
listen sync --fake                every seam of the sync, offline

listen audio                      what this Mac holds, and what each device keeps
listen audio <id> --build         make one master here, and say what it cost

MCP

{
  "mcpServers": {
    "listen": {
      "command": "/usr/local/bin/listen",
      "args": ["mcp"]
    }
  }
}

Settings, Developers has this ready to copy with the right path filled in.

Opens no port, and the app does not need to be running: the library on disk is the source of truth.

Notes, tags, your dictionary and a recording's name are the only things an agent can write. Everything else is read-only, and that is a boundary rather than a milestone. An agent can add, rewrite and delete the notes it wrote, tag and untag a recording or a note, and name a recording nobody has named; it can read your own note and tag it but not change a word of it; and it cannot rename a speaker or delete a recording.

Recordings and notes share one set of tag names, and nothing is inherited: tagging a meeting kinsight does not tag the write-ups of it, so filing a subject means doing both. That keeps two questions apart that are worth asking separately, what was said in meetings filed under this and what has been written up about it.

The line is between evidence and opinion. The transcript is a record of what was said. A note is somebody's reading of it and a tag is somebody's filing of it, both reversible and both visible in the window the moment they land, so a wrong one is a wrong opinion sitting beside the recording that disproves it. A wrong transcript edit is a fact that is simply gone. Changing the evidence goes through you, in the window or at the command line, where you can see it and undo it.

The dictionary is the one that needed thinking about, because a rule is harmless and applying it to transcripts you already have is not. Adding one changes nothing that exists: it says how the next recording should be spelled, and it can be taken back. Rewriting the ones you have is offered too, because a rule that fixes tomorrow and leaves the meeting where you noticed the mistake spelled wrong for ever is no use, but it takes no backup, so an agent cannot reach it without first showing you every sentence it would change: the call refuses unless it carries the count that preview returned.

It can also see what it could not before: the meetings coming up on your calendar, the questions you have asked it in the past, and how much of the library its own memory of your people has actually read. Those are all reads. Where it finds a claim in that memory misreading its own source it can say so, and that waits for you: listen context suggestions --accept applies one, --dismiss stops it being offered again.

Twenty-nine tools, nineteen of which write nothing. MCP.md is the reference: how to connect each client, what every tool takes, and how to walk a large library without reading it whole.