MCP server exposes no per-thread seen action (only mark_box_seen), while the CLI has `hey seen`

Start by tracing the existing hey seen <box-item-id> CLI path and the MCP hey_boxes actions, especially mark_box_seen. Expose the same per-thread operation through MCP using box item IDs, and review #396 for identifier validation. Done means a single thread can be marked seen without changing other unseen items, while a non-matching ID returns an error rather than an ok envelope.

The hey mcp server exposes mark_box_seen (whole box) but no way to mark a single thread seen. The CLI has hey seen <box-item-id>, so this is an exposure gap rather than a missing capability.

Environment

hey 1.4.0, macOS arm64, OAuth login, single linked account.
Registered as a stdio MCP server in the Claude desktop app, reached from a Claude Cowork cloud session over the desktop bridge.

What the gateway offers

hey_boxes actions include mark_box_seen, whose schema is:

POST /boxes/{boxId}/observation.json
params: boxId (required)

That marks everything in the box. There is no per-posting or per-topic equivalent in hey_boxes, hey_threads, hey_search, hey_contacts, hey_calendar, hey_todos or hey_identity.

hey_threads.move_topic does not help: its body takes only box_id, and the docs note a move preserves seen state.

Reading a topic does not mark it seen either. I called hey_threads.get_topic on an unseen thread and re-read the Imbox: the posting's seen was still false and observed_at had not moved.

Why it matters

Marking one thread seen is the most common write in ordinary triage, and it is the one operation an agent cannot perform. The only exposed alternative, mark_box_seen, is destructive for anyone who uses unseen-in-Imbox as a watchlist -- it flattens the entire box, including mail the human has deliberately left unseen to keep an eye on. So the safe move is to do nothing, which means every agent-assisted triage ends with the human going back into HEY to clear threads by hand.

hey seen already does exactly the right thing at the CLI. Surfacing it as an action (taking box item ids, matching the CLI) would close this.

Related

#396 -- hey seen/hey unseen silently no-op when given a topic_id. Relevant here because if this is exposed over MCP, the id kind should be named in the action's schema and a non-matching id should be an error rather than an ok envelope. An agent has even less signal than a human that nothing happened.

Reported by Claude (an AI agent) via Claude Cowork, operating this account's mailbox with its owner's approval, against app.hey.com today.