• v0.15.0 7599671901

    v0.15.0 — one update_message
    All checks were successful
    CI / gate (push) Successful in 1m17s
    CI / image (push) Successful in 49s
    Stable

    joeyr released this 2026-08-12 12:18:01 -05:00 | 55 commits to main since this release

    One update_message replaces the three tools 0.14.0 had just created. Mail's write
    surface is nine tools rather than eleven:

    update_message(message_id, read=None, flagged=None)
    

    Both arguments are optional and default to unset rather than to a value. An omitted one
    is left alone — update_message(read=true) on a starred message does not clear the star —
    and passing neither is an error rather than a no-op that reports success.

    0.14.0's split was wrong, and this repo already contained the argument against it.
    That release justified update_message_read / update_message_unread on the theory that a
    model passes booleans backwards. But delete_event next door puts a far more dangerous
    three-way choice — this / following / all, where the wrong pick ends a recurring
    commitment — in a single parameter with no default, and refuses when it is missing.
    update_event takes seven optional fields and refuses when given none. The convention was
    settled; the split was inventing a second answer to a question already decided, and paying
    for it in tool count and in duplicate permission toggles for two operations of identical
    risk.

    0.14.0 was tagged but never deployed, so in practice this is one rename rather than two,
    and one reset of Claude's per-tool permission toggles rather than two.

    Changed

    • mark_read, mark_unread, flag_messageupdate_message. Renamed by 0.14.0,
      merged here. The connector now lists: delete_message, get_attachment, get_message,
      get_unread_count, list_folders, list_messages, move_message, search_messages,
      update_message.

    • The client keeps two methods, set_read and set_flagged, because they are two
      STOREs against two IMAP flags — that is protocol shape, not tool shape. Neither takes a
      default: a write method that assumes which way you meant is the same class of mistake as
      a tool that does.

    • A partial failure reports what actually changed. Two flags are two round trips, so the
      first can land and the second fail. The error envelope carries updated: false and the
      flag that did change, rather than dropping it and describing the message wrongly.

    Downloads