Read the replies on your Threads posts through the same call you use for every other network, and know when a read failed rather than mistaking it for silence.
One call returns the replies on a post you published, paged with a cursor, in the same shape as every other network.
curl "https://api.postlake.dev/v1/posts/post_…/comments?limit=50" \
-H "Authorization: Bearer $POSTLAKE_API_KEY"Every list also returns problems, naming any network that could not be read. That field is the point: without it an empty list is ambiguous, and "nobody commented" is indistinguishable from "we could not look". An agent acting on the first when the second is true will draw exactly the wrong conclusion.
Threads allows replying to someone else's comment through the API, so a reply is one more call with the comment id.
Threads also supports a first comment: a reply posted automatically on your own post the moment it publishes, which is the usual home for links and hashtags you do not want in the caption.
Threads does not expose a notifications feed to applications, so comments are read per post. Networks that do expose one are merged into GET /v1/notifications.
Yes, on posts you published. PostLake returns them cursor-paged in the same shape as every other network, alongside a problems field naming anything that could not be read.
Yes on Threads, with the comment id. The reply goes out as your connected account.
Every list carries problems. If a network could not be read it is named there, so an empty list is never mistaken for silence from your audience.
Yes. Over MCP it is read_comments and reply_to_comment, and you can restrict which brands and networks a given agent may act on before you let it run.